As a break from that problem, today I’ve been fixing a couple of small user bugs and trying to reduce the overall memory usage a bit now that I have been getting more and more users with > 1 million triangle models lately.  This is not what I wanted to do so close to a release but the trend lately is large files and I don’t want to lose those users to other programs.  The changes I’m making require a complete recompile of the program since these are core data structures.  Each build takes about 20 minutes.  As you can imagine, errors are frustrating when they mean I have to wait another 20 minutes to rebuild.  Hopefully this will have some payoff.

Also, the analytics data is starting to flow in and I finally have enough to start looking at it to draw some simple conclusions.  So far I’ve been blown away by one feature being used extensively that I almost dropped because I don’t hear from many people using it.  (Sorry, I can’t share exactly what that feature is- I’d hate to help competitors).  If the trend in the data continues, and I can update the analytics to give me a bit more detail, then I’ll probably look at what I can do to expand the feature in the future.

I’ll say it again, if you want your favorite features to get extra attention then please enable the Customer Experience Program when installing the program.

http://www.grzsoftware.com/v2dl.php

1. A small file with some lines, arcs, circles, and maybe a freeform curve.
2. The files should only have a few entities so I can debug it manually if I have to.
3. The curves should be converted to polylines on save.
4. Please name with file something based on the name of the CAD program and the settings used to generate it.  For instance rhino4-acad2004polylines.dxf if it were from Rhino with the “Autocad 2004 Polylines” save option.

You can send them to me or post them in the DXF thread in the Development forum.

Thanks in advance.

Richard and I spent about a month trying various updates and tests to find the root cause.  By the second week of testing I was contacted by another user with similar problems so I began to get really worried.  Along the way I found a similar problem caused by a missing manifest file for the tbb.dll file that MeshCAM depends on, although this didn’t help Richard at all.   I was just about to have him dig into Dr Watson to get me a dump file when I though, “I should check out the blog to see what I was talking about near Build 5.”  Sure enough, I saw that I made the change to SSE2-only CPUs at this time and, sure enough, Richard had an Athlon XP CPU that lacked the necessary SSE2 support.

By now, I’ve wasted enough time with this (because I didn’t bother to read the blog) and I never want to deal with this again.  The new installer includes both SSE2 and non-SSE2 builds and will automatically install the right one when the installer is run.  I should have done this at the start but I really didn’t think that old CPUs would be commonly in use for higher-end applications like CAD/CAM.  My assumptions have failed me again but hopefully this will solve the problem for good.

Build 10 also include updated translations for Spanish, Japanese, and Russian.  The German translation is not ready yet so that will be build 11 which, if no bugs are reported, will become the “release version” of MeshCAM 3.

It would help if users could check the about dialog after install to see if there is the phrase, “No SSE2” is there.  It should not be there for Pentium 4 or Athlon 64 and newer chips.  P3, Athlon XP and older should show “No SSE2.”

As always, let me know what you find in this release.

http://www.grzsoftware.com/v2dl.php

Now that I’ve seen evidence that my development efforts are not exactly aligned with the day-to-day behavior of my users, I see the point of these feedback programs.  Very few users give feedback so it’s difficult to get a information about what they want.  In retrospect I see lots of wasted development time that could have gone into more desirable features.

Moving forward, MeshCAM will give you the option of participating in a program to send usage data back up to my server so I can see what functions and commands are used most often.  Development on V4 development should be much quicker if I can focus my efforts only on what people actually use- and maybe phase out the features that are not. 

The data sent back is a list of commands used and some file data like the number of triangles an STL when it’s loaded- there is NO personal data and nothing that can be mapped back to a particular user.  There is nothing sent that contains any part of your name or registration code.  Further, all data is held in an “analytics” directory in plain text so it can be reviewed.  It is transmitted as plain text so someone could confirm that the transmitted data matches the recorded data.  Transmission takes about 1-2 seconds on shutdown.

You will be able to opt out of the program but I would hope that everyone would choose not to- this is the best way to collect the data that I need to make the program more relevant to it’s users.

So my question for you all, does the brief text in the installer pane below give enough information to encourage someone to opt it?  If you are the type that would generally not participate in these, would the text below sway you?  If not, what would?

I’m still eager to get any bug reports as you play with this build or build 7.

I had not expected to call V3 “done” this quickly but I started reading back through the postings here last week and I saw that V3 has been underway for the better part of the year.  Somehow I thought it had only been a few months but it looks like my horrible sense of time has struck again. 

Version 3 has diverged from where I though it would go but I think the improvements are significant enough to make this a major update even if I didn’t get everything done that I wanted to.  I also want to get V2 removed from the site completely and this is the only way I can do it.

Please download the latest release and let me know what you think.

In the past few months I’ve made some big changes that inadvertently broke features that have been in MeshCAM for a long time and nobody noticed (or they didn’t let me know about it), and I found a couple of bugs that have existed for years but have never been found.  Based on this, I think I’ve misjudged the importance of some of the features I’ve put in there, because nobody seems to be using them.  Version 4 will begin development near then end of the year and the priorities will have to be adjusted to reflect my new understanding of the average user.  I’m thinking development will be focused more on solidifying the core and only adding a few new features.  I’ll probably ask for more feedback at that point so start paying attention to the features that you actually use on a day-to-day basis.

Also, I haven’t gotten many bug reports on the last version and I’m sure there are bunches of bugs lurking.  Please let me know what you’re finding with the last release.