The v2 beta installs into its own folder, it is not a problem to have v1 and any v2 beta installed on the same machine, in fact I recommend that so that you can fall back to v1 if you run into some temporary bad bug in v2.

New stuff for this version:

Major overhaul of mesh exporting to greatly increase mesh generation speed and to make use of multiple CPU cores.

It would be great to get some timing benchmarks of the new meshing speed!

If you have a heavier model that previously took quite a while to save to a mesh, if you could take 3 different benchmarks that would help to gather some information.

One measurement on version 1.0, one measurement with the new Jan-19 v2 beta, and if you have multi-core then one measurement with a setting in moi.ini edited to limit to it to only 1 CPU core would be helpful.

That final one will help me to see how well it is scaling across CPU cores on some different people's machines.

The moi.ini setting for limiting it to only 1 CPU core is:

[Mesh Export]
ThreadLimit=

Set that to ThreadLimit=1 to limit it to 1 CPU core

Close down MoI first before editing moi.ini and the moi.ini file can be found in WinXP here: C:\Documents and Settings\Michael\Application Data\Moi\moi.ini

Then after you're done set it back to a blank thread limit again to get back to full performance.

Some other notes - previously the meshing dialog would be frozen when it first appeared and you could only adjust settings after the initial mesh was finished being calculated. This is no longer the case, you can adjust settings and the current mesh job will automatically be canceled and a new job started with your new settings. Also I've removed the "Update mesh" button, instead now any changes you make will be applied automatically.

There is a new progress bar for the meshing job in progress, which is shown in the upper-right area of the main window underneath where the points and polygon count readouts are at.

Then with limiting to 1 thread, I get 3.62 seconds. This last measurement is primarily of interest just to me to understand if there is any problems with the scaling to multiple CPUs in particular situations like on particular models or on a particular kind of machine configuration.

It is possible for the multi-core stuff to be sensitive to a variety of factors so it may be helpful for me to collect some data on what speed increases various other people are seeing on their own machines and with their own complex models. If it is a lot different than what I see here there may be some things for me to tune up, but hopefully not.

Great job on the meshing, I will run the hydraulic connector when I get home in all three tests on my dual quad. I ran a smaller component(46000polys) on my work clunker and v.1 time was 1:24 and v.2beta was 8 seconds. Great job Michael.

> I just wish that it placed triangles better in quad+tri mode
> now... Right now it makes a mesh that is very hard to
> UV unwrap.

I don't know if it will help any or not, but there is one setting in the moi.ini file which tweaks how triangulation is done:

[Mesh Export]
CentroidTriangulation=y

With the default of =y then it will try to produce a kind of radial triangulation connecting points on an n-gon outline to a centroid point if possible. With it set to =n then the triangulation will only be connecting points on the outer n-gon outline to one another without adding in a new center point.

If you have an example of an existing shape that is not getting triangulated how you would like, could you please post the .3dm file of it, and maybe show how you wish it was triangulated instead? That would help me to think about how to tune it up further.

One thing that I have thought about before is trying to carve up a larger outline into some sub chunks to try and do centroid style triangulation on some sub pieces of a single big outline.

Hmm - from V1 15 minutes to V2 23 seconds is a factor of nearly 40! That's certainly a record so far.

I tend to get something around 20 to 25x on my quad core over here, so your measurement is fairly consistent with around double that, but your measurement with the new engine limited to a single core seems to show that there may be some further tuning possible. I'm not very sure that I will be able to do that right now though, further tuning beyond this may be fairly hard work. One thing that is very good though is that it does not choke with 8 cores running, it is actually possible with multi-threaded code to get cases where increasing the number of cores actually makes things worse instead of speeding things up, if there is a problem of too much "contention" between the cores.

Re: running out of memory - yeah since now you can more easily spew out a huge number of polygons there is also an improvement to handle out of memory conditions better, instead of just crashing or something it will show that warning when it ran out of memory when trying to complete the current task.

I guess that probably happened when you got most or all of the 8 cores happening on crunching away on those long helix surfaces, those will kind of spike to a higher level of memory consumption during their subdivision process, so getting a bunch of those all going at once will put a pretty big spike in memory consumption. It will bump back down after each one is finished and the final mesh is extracted but if you bumped up beyond your full system memory during the spike, that will be a problem.

That's kind of an interesting problem with a higher number of cores that I hadn't really considered too much.

> opening of files seems a little snappier too (might just be
> the excitement))!!!

I think that opening of files should probably be the same... Probably just some feeling of momentum carrying over from the other speedups! :)

But now that I have a thread-safe meshing mechanism it will open up the door for me to do some things that will speed up file opening for real though.

I should be able to get the display mesher to run on multiple cores now - currently the display mesher (which is used during file open) does not use multiple cores, only the file export mesher is doing that now.

Then the other thing that I've been thinking of doing is to do an initial pretty rough display mesh (or even skip doing it and have only edge wires initially if it takes more than a couple of seconds), and then do a higher density display mesh calculation in the background. The higher density display meshes would kind of spool in while you are able to do other work on the model.

Those are some ideas anyway! Actually I don't think these will be all that difficult, the difficult part of these was to make the meshing engine thread safe which is all done now. But kind of a good first stage is to get that tested here first with the export meshing in this new release.