I love memtest86 - I run it on all my computers after i have built them up and they get left on that for at least 10 full cycles or even up to 24 hours. Admittedly this RAM has not been re-tested and it's now very nearly a year old. I hate trying to solve intermittent failures like this because you think you have it sorted right up to the point where it does it again.

I have been a staunch fan of AMD processors but their continuing failure to keep up with Intel is starting to sway my opinion, once the new Bulldozer II's are on the scene and have been tested i will bet in a better position to say what the new box will have inside it ? Now that I am favouring MoI over Rhino these days do you have to or intend to do any code tweaking to make MoI more responsive to AMD's single core based application problems (AMD's new processors suck on applications that do not use more than on core) or is this problem down to MicroSoft and AMD to sort out ?

Martin

Hi Martin, well it sounds like you already know how to handle it!

> I hate trying to solve intermittent failures like this because you think
> you have it sorted right up to the point where it does it again.

Yeah intermittent failures are definitely the worst, and sometimes there isn't any really good way to solve them aside from one-by-one swapping components out with a new one, but of course that requires a duplicate set of all your system components to be available.

But if you can reproduce the failure while running under memtest86 that should really help to narrow it down though since it should take other stuff like the video card out of the picture and probably then more directly point to bad RAM or I suppose possibly the CPU but most likely RAM.

From what you are describing behavior wise bad/flaky RAM does sound most likely.


> I have been a staunch fan of AMD processors but their continuing failure to
> keep up with Intel is starting to sway my opinion, once the new Bulldozer II's
> are on the scene and have been tested i will bet in a better position to say
> what the new box will have inside it ?

Intel certainly does seem to be a fair ways out in front these days I guess unless you are running some kinds of server oriented stuff.

I myself have just recently built a new box with a Core i5 in it, which has a reasonable price.

There doesn't seem to be anything particularly wrong with the AMD stuff, it's just lagging behind in performance to a certain degree but certainly will certainly still work fine in general.


> Now that I am favouring MoI over Rhino these days do you have to or intend
> to do any code tweaking to make MoI more responsive to AMD's single core
> based application problems

I do intend in the future to add more things that take advantage of multiple CPU cores. But dealing with parallel execution tends to be very tricky though, and it's notoriously easy to create really difficult to nail down bugs with it, so it tends to be a particularly delicate and time consuming area of coding work.

- Michael

Hi Michael,

> I do intend in the future to add more things that take advantage of multiple CPU cores. But dealing with parallel execution tends to be very tricky though, and it's notoriously easy to create really difficult to nail down bugs with it, so it tends to be a particularly delicate and time consuming area of coding work.

We discussed the perils before with multi-threaded apps, and yeah i understand the problems associated with them, i was just Referring to the way the new AMD chips process single core apps, I know that Microsoft had to release patches for XP onwards to handle the code better within the their OS's, I just wondered if you needed to tweak MoI to make it better suited to AMD cores, or whether it's a "guts of the OS" problem ?

Martin

Hi Martin,

> I know that Microsoft had to release patches for XP onwards to handle the
> code better within the their OS's, I just wondered if you needed to tweak
> MoI to make it better suited to AMD cores, or whether it's a
> "guts of the OS" problem ?

It was a "guts of the OS" problem - something to do with adjusting the behavior of the thread scheduler that distributes threads to run on the different available CPUs.

Once the patch is in place for it, it solves the problem at the system level and so individual applications do not need to do anything extra to avoid that particular problem.

- Michael

Hi BurrMan,

good you mentioned the 'standalone' versions, as I was only drawn towards the Rhino plug-in.
I will try out the 'closed obj forms and will give you some feedback if I could get it to work
on parallels on a mac.

Jan

Hi BurrMan,

the resurf 3d program crashes immediately the moment a *.obj is loaded on my installation.
I tried objects exported from MoI, Cinema 4D and Rhino yet all of them crashed the program.

The surface program instead worked fine and created pretty good results. The pricing though
is way above my need to use it.

Yeah, I had poor results with the obj one too. But I think it just needs more time put in to learn what it is expecting.. It is a very tricky area... The surface one works. You just need to open up your models, so you cant really do "entire heads" and such.

The other thing, is like mentioned in the original postings, the NURBS surfaces created will be "HEAVY", if you are trying to match anything of detail... Pretty much not a workflow to use. The higher end ones I think will produce something more usable though... But if $120 is out of budget, then $15,000 is pretty much not looking too good either!!! lol The other thing with the expensive ones... I think there needs to be lots of time put into the understanding of whats happening and "when, why and how" type stuff.. It's not just pushbutton. So a couple years to get good at it.

There is a great script to toggle between 3 different settings that will cycle between 5 10 and 25 then back to 5 you can change them yourself , for quick detail adjustment. just copy into the command line

script: /* Toggle mesh angle */ var newang, ang = moi.view.meshAngle; if ( ang == 5 ) newang = 10; else if ( ang == 10 ) newang = 25; else newang = 5; moi.view.meshAngle = newang; var sidepane = moi.ui.getUIPanel( 'moi://ui/SidePane.htm' ); var endsection = sidepane.document.getElementById('MiddleBody').nextSibling; if ( endsection.lastChild.id != 'angval' ) endsection.insertAdjacentHTML( 'beforeEnd', '' ); endsection.lastChild.innerText = newang;

cheers
shayne

Just wanted to throw my wishlist in also!

1. 64-bit, So I can handle bigger data sets in moi3d, hopefully this means increased in performance also.

2. Separate surfaces base on edge selection(i.e. edgeloop) This will save me lots of time!

3. Lattice deformer: I can see this opening up many possibilities for free form modeling!

4. Improved Network

5. Fillet multiple edges with different edge width

> Lattice deformer (???)

Is that the same thing as "Cage Edit" in Rhino and the NURBS equivilant to Sketchy FreeForm Deformer in SketchUp?

See Here: http://www.rhino3d.com/5/help/commands/cageedit.htm



Man, I would love that tool!!!


Michael, I have a request that just occurred to me. :-/
Would it be possible to add the ability for Circular Array to have a two-point, 3D axis? (just like the Revolve tool lets you do)

Yes, there are three ways to work around this. 1) Rotate your object to a flat plane, go to a view and Circular Array... then rotate back. 2) Change your view-plane axis (that scares me a little still). 3) Use Rotate by axis... but you gotta know your angle.

A circular selection

Hi Mike, yeah right now the main way to do the circular array by 2 points would be to set your construction plane (View > Cplane) to have its z axis running along the axis you want to use. Then when you're done it's easier to reset the cplane (right click on View > Cplane) than it is to relocate objects around.

It could still be a possible feature to add in an axis to the circular array command, but do you need some tips for working with the construction plane right now? Would you like to start up a new topic with an example file that has an axis line in it and an object you want to array so I could show you some steps for setting up the cplane?

But basically if you draw in a line where you want the array axis to go, if you then place the cplane onto the start point of the line, it will automatically orient its z axis to point along the line's direction (unless you turned off "Align to objects") so you don't have to do any other fancy repositioning after the initial placement, you would just right-click to accept the default orientation and then your drawing plane will be set to the plane you need. Then when you're done with the array right click on View > Cplane to reset it back to the default world axes.

- Michael

> Would you like to start up a new topic with an example file that has an axis line in it and an object you want to array so I could show you some steps for setting up the cplane?

Thanks Michael! Yes, I'll do that...

Oh! I can Blend and Loft a cat and dog together, but these "orienteering" tools to me, are like that last can of food in a famine that just happens to be sardines! (you're so hungry... but yuk? :-/ )


I wouldn't mind a two-point (3D-space) axis option in the future for Circular Array, does works great for Revolve. :-)

>>A circular selection <<

2nd that. :-)

Peace,
Rich_Art. ;-)

64 Bit support! Sure there are ways to reduce (for example) exporting of heavy models, but using the full 16 Gigs on my system would surely help to avoid the ever-occuring "Insufficient memory" error, or not? Not really sure of all the actual pros/cons of a 64-Bit compared to a 32-Bit. But is that really a question these days.? 64-Bit is eventually the way it will have to go anyway. Or is there a reason to hold out?

Hi Tree,

> Or is there a reason to hold out?

The main reason is just the amount of work required on my part - producing a 64-bit version would be a major undertaking, I would need to switch to a different compiler, update all libraries that MoI uses and deal with changes and incompatibilities from that, and then also manage more versions of MoI since I don't think I can drop the 32-bit version right now since there are still a lot of users on somewhat older 32-bit machines.

The amount of work involved is enough that it's unlikely to happen anytime too soon - if I were to dig into it, it would require a lot of time focused only on that which would displace quite a large number of other features.

- Michael

@ Magic, yup that is a lattice deformer - Ideally it should work on Solid too (if that's possible)

Yes it should, considering that the cage control points only represent a matrix of spatial relationships.

All of the control points, and other surface-related coordinated would simple conform to the manipulation of the cage space. (??)

The cage would be made of a X by Y by Z lattice of control points, meaning that you could manipulate the cage points lying within the interior arrangement of the cage and allow for warping of your objects throughout.

Understandable. Although that seems to be just postponing the inevitable doesn't it? As the versions of Moi get "heavier" it will become more difficult I suppose. Just something that I've been seeing often lately with the newest v3 Beta Build while trying to export some heavy models with the "Insufficient memory" error coming up often. Or maybe this is related to the Beta itself? I don't recall having problems with exporting in the past, but maybe I just hadn't been working with heavier models. Moi is still my go to app for converting surface models to polys, but I also don't imagine that the models will get any "lighter" in the future.

Cage editing = "Soft selection" for MoI's points.