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;
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.
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.
> 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. :-)
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?
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.
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.
> Understandable. Although that seems to be just postponing
> the inevitable doesn't it?
Yes, but it's not like that's unusual at all - postponing things that require a lot of work is a normal part of the software development process, particularly when working with very limited resources.
> Or maybe this is related to the Beta itself?
Not as far as I am aware of.
> I don't recall having problems with exporting in the past, but maybe I just hadn't
> been working with heavier models.
Yeah it's probably that.
> 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.
You should be able to avoid the problem by selecting just some portion of your objects (just half of them is a good thing to try at first), and then using File > Export to write those out. Export is short for "Export selected" and it writes only the selected objects out rather than everything all at once. Then after you've exported one half invert the selection and export the other half to a different file, then in your rendering program import both of those files and then you should have it all transferred over.
MoI is really more primarily focused on being a modeling tool where you create stuff in, it's somewhat more of a side effect that it happens to be good at converting existing CAD assemblies to polygons as well.
I think it will be possible in v3 for me to tune a couple of things up in some of the intermediate processing stages that will help to reduce memory consumption somewhat though. There are also other feature areas like instancing that can actually help out a lot more which I would probably be working on before trying to tackle 64-bit.
> Does it possible to have the generator's curves in a different
> color than default color?
By default colors of objects are controlled by what style they are assigned to, so if you want curves to be a particular color assign them the style you want.
I have remarked than using the Blend function this last want not works, because curve generators were again present and were selected against the real edges of surface!
So a different color should warn the user that 2 curves are overlaped!
> So a differnet color should warn the user that 2 curves are overlaped!
But it is a feature of MoI that you are free to choose the colors of objects as you desire so that you can use style colors for your own organization scheme.
This kind of "use automatic color for certain objects" type of system like you are describing would be in conflict with the "you are able to set object colors as you wish" system that is currently used.
