Difference between revisions of "FAQ"
Line 2: | Line 2: | ||
== Q: When will MoI version 1.0 be ready? == | == Q: When will MoI version 1.0 be ready? == | ||
− | + | Very soon! | |
− | |||
− | |||
+ | Just working on a few last details for the installer and license keys. It should only be a few more days from now (1/12). | ||
== Q: What about a Mac or Linux version? == | == Q: What about a Mac or Linux version? == |
Revision as of 04:14, 12 January 2008
Frequently Asked Questions
Contents
- 1 Q: When will MoI version 1.0 be ready?
- 2 Q: What about a Mac or Linux version?
- 3 Q: Why can I export to .obj format, but cannot read .obj format into MoI?
- 4 Q: Why does show points work for some objects but not others?
- 5 Q: Why do I get small shading errors when exporting to some rendering programs?
Q: When will MoI version 1.0 be ready?
Very soon!
Just working on a few last details for the installer and license keys. It should only be a few more days from now (1/12).
Q: What about a Mac or Linux version?
I have heard from quite a lot of people wanting a Mac version of MoI, so I don't have any doubt that there is a demand for it. It would actually be a really nice fit as well since MoI's UI would just fit in well on a Mac.
If it was easy to produce a Mac or Linux version, I would certainly do it!
Unfortunately it is very much the opposite of that, it would involve a huge amount of work, maybe something like a year (or easily even more) of working full time just on that alone. It will take quite a while before I will be able to gather up that much time.
Choosing between that and adding a year's worth of modeling features to MoI, right now I have prioritized working on modeling features and adding new functionality instead of porting.
So currently there is no plan to have a Mac or Linux native version out anytime soon.
One thing that may happen sooner than a full port would be some changes to the display system to enable running under an emulation system like Parallels (currently this doesn't work because Parallels does not emulate the Direct3D system well enough). It's still a fair amount of work to do that so I'm not sure when that will happen but it is much less work compared to a full port.
One last note - if you have one of the newer Intel-based Macs, you can use Apple's Boot Camp system to install Windows on your machine, and when you start your computer you will have an option to use either Windows or Mac OS. Booting to Windows in this way will run MoI fine because you are just running Windows directly in that case, not under an emulation system.
Q: Why can I export to .obj format, but cannot read .obj format into MoI?
MoI is focused on modeling using NURBS objects, which are made up of smooth curves and surface patches. It's a significantly different way of structuring an object than a polygon mesh method, which is the kind of data that is contained in .obj, .3ds, .stl and .lwo files.
When you export from MoI to one of these polygon mesh formats, MoI will dice up its smooth surfaces into smaller polygon facets to create a polygon mesh. But it is not easy to go the reverse direction and take diced up polygons and create larger smooth surfaces back from them. It's kind of like how you can take a bunch of apples and smash them into applesauce, but it is hard to start with applesauce and go back to apples.
If you want to use a polygon mesh object as a kind of reference object to snap on to while drawing something new in MoI, check out this tool: Obj23dmWireframe converter which will allow you to convert all the edges of a polygon mesh .obj file into a line segments in a .3dm file which can then be loaded into MoI. That enables you to basically use the wireframe of the mesh in MoI as a guide.
Q: Why does show points work for some objects but not others?
MoI won't let you turn on points if you have an object made up of joined surfaces, where the surfaces do not have aligned control points along their common edges. This can happen easily when surfaces are intersected such as in the Boolean commands.
The points are not shown in that situation because it would be too easy to drag the points and cause a gap to open up along what should be a shared sealed edge.
You can get the points to turn on by using Edit/Separate to break your joined object into individual separate surfaces. You can always show points for an individual surface because it does not have this "pull apart shared edge" issue, since it doesn't have edges shared with other surfaces anymore.
Here are some pictures to explain it further.
Here is a plane and a cylinder that I have intersected and trimmed with one another:
Here are the control points for the cylinder surface:
Note how there are no control points along the intersection edge with the plane - that edge is what is called a "trim curve", it is a curve that has been calculated that exists on the surface, but it is not directly connected to the control point structure of the surface. So you can't modify the surface by pulling on the trim curve itself, the trim curve has its own control points that are separate from the surface's control points.
Here are the points for the plane, just 4 points at the corners:
So you can see here that the 4 points for the plane do not match up in any way to the control points for the cylinder. here is what happens now if I grab one of the points of the plane and drag it, it opens up a gap:
This is kind of a fundamental thing for how NURBS modeling works, it has to do with the creation of those "trim curves" that live on a surface but are separate from the surface's control points.
After you have surfaces connected to each other by trim curves like these, you can't easily make modifications by moving surface control points around and still have the connections between the trim curves stay intact.
So the whole trim curve system does not really lend itself to point squishing - however it is also the key thing that makes Boolean operations work really well with NURBS models, since as you do multiple Boolean operations the surfaces themselves don't change, just new trim curves are calculated. With a polygon type modeler, each boolean operation actually dices the polygon surfaces themselves up into a whole lot of small pieces. But since polygon modelers do not have trim curves, they stay a lot more squishable by point manipulation.
Q: Why do I get small shading errors when exporting to some rendering programs?
That usually means that your rendering program is not reading in the smoothing information and is trying to calculate smooth shading by just averaging the normals between adjacent polygons. That kind of automatically calculated smoothing can easily lead to glitches especially in areas where there are polygons of different sizes next to one another.
If you can instead get accurate shading normals into your program, it will avoid these kinds of glitches and help get super smooth looking renderings.
To get accurate normals, first you need to use a file format that supports vertex normals. Usually .obj format is the best choice, except use .lwo for Modo and for Blender use .lwo along with this Blender import script. Avoid using file formats that don't support normals such as .stl and .3ds.
Sometimes when importing an .obj file into your application, there will be some checkbox options for "use normals", or "load vertex normals", etc... - make sure that is enabled.
Also some programs cannot deal with welded meshes in the .obj file, so turning welding off can help in some cases. For example turning welding off makes normals come through ok to Electric Image. To turn welding off, during the mesh export click the little arrow in the lower-left corner of the "Meshing options" dialog box to expand it to detailed settings, and uncheck "Weld vertices along edges".