I created a bridge in Moi, and exported it as 3ds for use in SketchUp. In Moi it looks fine, but in SketchUp I get “wrinkles” in the geometry where it should be smooth. How can I fix this?

Another problem I had was related to scale. When modelling the bridge in the actual scale the geometry seems to become heavier than if I do it in a “miniature scale” (something that will fit on the visible grid). In real scale the Booleans would fail, I was unable to fillet, and lofts had “flaws” (wouldn’t fit the given shape). Should this be happening, or did I miss some settings for use with big models?
By the way, it would be very nice to have warnings explaining why some operations have failed; “Filet radius is too big for the selected radius (at this location)” or “Surfaces around the filet are not joined” etc.
Sheik

Hi Sheik, that definitely looks odd.

If you could post your .3dm and .3ds file (or send them to me at moi@moi3d.com if you want to keep them private), it could help me figure out what is going on.

Do you have objects with very large coordinates, or very far away from the origin? Things like that could conceivably cause this kind of jiggling around because coordinates like that will lose digits of accuracy due to the way that floating point math works on the computer, especially the "single precision" numbers used in .3ds format.


> Another problem I had was related to scale. When modelling the bridge
> in the actual scale the geometry seems to become heavier than if I do
> it in a “miniature scale” (something that will fit on the visible grid). <...>

This is a problem in general with NURBS modeling - many operations need to be calculated to a tolerance level, and right now in MoI this value is 0.001 units.

If your object is a much larger scale than that, then 0.001 units is way too accurate and will cause extremely dense fitting of intersection curves.

For now in MoI you shouldn't really create your model to be much larger than 10,000 units or so (really in the 1,000 range is better), and also not far away from the origin as well.

I would like to experiment in the future with a kind of adaptive tolerance to make large scale models work better without excessively dense fitting accuracy, but it is a pretty complex thing to nail down very well.


> By the way, it would be very nice to have warnings explaining why
> some operations have failed; “Filet radius is too big for the selected
> radius (at this location)” or “Surfaces around the filet are not joined” etc.

In the future I would like to work on this, it is quite a bit more difficult then it seems though.

- Michael

I did some test with the same model.
-The 3ds file looks the same in other apps, so it is not a SketchUp import problem.
-I exported with fewer polygons, and the problem becomes worse.
-I exported the same model from MoI as *.obj quads, and then imported to Rhino, and then exported it as 3ds. (SU doesn’t import obj). This 3ds file looks clean in SketchUp.
-I have seen similar wrinkles before in models I exported as 3ds from MoI, and some were small objects, so it is probably not just a scale issue.
Sheik

I opened the 3dm file in Rhino, and exported it as a 3ds file. It imports witout the wrinkles to SketchUp.
Sheik

Hi Sheik, there does seem to be some problem with the mesh generation in MoI on this model.

It appears that one area of the mesh is not getting subdivided in that tightly curved area.

So there is a region with a more tightly subdivided area (which then hugs closer to the true surface) right adjacent to a non-subdivided area (which causes a kind of "chord" away from the true surface) which creates a kind of bumping effect.

In the meshing options dialog, if you move the slider over to the right a ways (towards the "More polygons" direction), it can help to avoid this problem right now and create a more proper even subdivision.

I'll take a closer look and see if I can figure out what is going wrong in this case.

- Michael

It appears to be caused by the "seam edge" of the surface having an extra subdivision beyond what the surface has.

That creates just one point on the edge that is more accurate than the points around it.

It should only be an issue when you have a somewhat rougher mesh generated.

Like in this case here when you have the default density, the mesh generated is fairly rough length-wise because the surface is not highly curved that direction:



You can see there that not a lot of polygons were generated length-wise, that's because the default angle tolerance for the middle of the slider is 12 degrees and those pieces are just barely within that angle, there's about an 11 degree angle between those length-wise sections.

So this creates a pretty big "chord" where the midpoint of those longer mesh edges are a fair distance away from the actual surface. When there is suddenly a more accurate point thrown in right in the middle of those it creates the kind of bumps that you are seeing.

At the moment the best solution when you see this is to move that slider over to the right so it is more like 3/4 of the way over. That will cause additional subdivision so that you don't have as much "chordal" type deviation between the midpoint of a mesh edge and the surface, so that makes it less of a big deviation when there is an additional accurate point thrown into the middle of it.

I'll see if I can do something about the extra point being added in to the seam edge. If I can avoid adding that point in it would solve this problem.

I have also thought a bit about adding in a kind of chordal accuracy measurement during the meshing to handle these kinds of areas better. Just angle alone gives too rough of a mesh in these kinds of shallowly curved areas. One problem though is that a chord distance is a scale-dependent value so it is difficult to produce one metric that works uniformly on both large and small sized objects. The good thing about the angle metric is that it is scale independent.

There are also some other controls in the mesher like "Divide larger than" which you can use to cause additional subdivisions of the mesh at certain distances. Those settings can help avoid the larger chord deviations as well.

- Michael

Michael there are some odd things about various files save types into or via other apps that I have not been able to fathom out. On any one MoI file, exporting as Iges may be best , on another MoI file export 3ds, on another Lwo, on another 3dm.

Hi Brian, well 4 of the formats you list there will rely on your target application to convert the NURBS data into a polygon mesh.

This includes your:

#1 .3dm from MoI -> import .3dm into Carrara (meshed on import into Carrara)
#2 .3dm from MoI -> import .3dm into Amapi (is this correct?) -> export .3dm from Amapi -> import .3dm into Carrara (meshed on import into Carrara)
#3 .3dm from MoI -> import .3dm into Amapi -> export .obj from Amapi -> import .3dm into Carrara (meshed on export from Amapi)
#4 .igs form MoI -> import .igs into Carrara (meshed on import into Carrara).

If you're seeing strange polygonization in any of these routes, you should contact the authors of the program that is performing the polygonization to see what might be going wrong. In all of these cases it is not MoI that is generating the polygon information.

The polygon information is what actually gets finally rendered, in all cases.

The route that I have the most control over is when you export a mesh format from MoI.

LWO is generally not the best except for going into Modo, LightWave, or Blender.

Programs other than Modo or the Blender LWO importer will not read vertex normal smoothing information from the LWO file, and instead will calculate smoothing by averaging adjacent faces. This can lead to some shading errors.

If you must use LWO export, it is probably a good idea to switch to Output: Quads & Triangles. If you export n-gons then you are also relying on your target application's ability to convert the n-gon into triangles, and this is another area which can be messed up fairly easily.

Generally the best bet is to use OBJ format, since that can translate vertex normal information over, which really helps to generate a smooth object.

Some programs deal with unwelded information better than welded information in OBJ files, so you might try expanding the meshing options dialog and uncheck "Weld vertices along edges".

OBJ file also have the option of using n-gons or quads & triangles. Again using quads & triangles here can help avoid n-gon triangulation problems in your target application.


So an overview: try OBJ export, switching 2 options - change Output : n-gons into Output: Quads & Triangles, and expand the dialog by the arrow in the lower left corner and un-check "weld vertices along edges".

Does that type of OBJ export work more reliably for you?

- Michael

Thanks Michael.
Following an earlier thread, I had reported two file type problems to Carrara (Daz).
I am surprised at the variations of import acceptability into Amapi and Carrara of identical files and, what you say I guess ties in somewhat.
This crazyness is way beyond a joke. Will that universal 3D file type Collada ever be properly organised?
I prefer to save in file types which keeps the various "parts" separated--so much easier for shading. To have to go through that slow creating of "shading domains" with obj files is a real drag.
Should I think of saving all the individual parts as individual obj file? Aaaahhhh!---It looks like it.

Carrara has allways been considered as not accepting obj n-gon files----a real nono!
I just did an exercise with that spray can and Carrara 6.03 accepted the (welllllll----that file!!!) n-gon version with relish?

AAaaaahhhhhh!

Hi Brian, give this utility a try:
http://moi3d.com/wiki/Resources#SeparateOBJ_editor

If you run your OBJ file through that SeparateOBJ.exe program, it will re-label some parts inside of it, and that may get Carrara to recognize different pieces without messing around with shading domains.

I'm not sure if it will work but it is worth a try...

- Michael

BRILLIANT!

Thanks Michael!

Hi Brian, does that handle what you were doing with shading domain stuff ok then?

- Michael

Michael--with GREAT caution!---maybe thats the solution!
IF its the answer, maybe that should be the DEFAULT Obj file save from MoI?????

? a Perfect all round solution?

Hi Brian, yup I think that will become the default save method for v2.

I'm glad that seems to help!

- Michael

And you are going to prioritise those "essentials" in that V2 version Beta in a couple of days?

When you get to my age you will ReALLY appreciate the fun joke!
"Once upon a time it was easy to do-------do!~ dodooo!"

All aside, your obj solution is about as good a "Collada" solution--geeesee it's so simple it makes the brain explode!

Hi Brian,

> And you are going to prioritise those "essentials" in that V2
> version Beta in a couple of days?

To tell you the truth, I'm not really quite sure yet how things will schedule for V2.

This particular thing involves material definitions on objects, so it may fit more naturally (without having to re-do stuff) after there is a way to assign properties to objects.

- Michael

Michael.
Prioritising is very very easy, you start off with the threads by a bloke BWTR and then alphabetically through the rest!
See how easy it was for me to take that decission weight off your shoulders>
Brian

Michael, getting back to that great learning post of yours (1392.8)
I would, never ever have considered unchecking the weld vertices as you suggested fo the obj save. Just the opposite!
The world is strange.

Anyway, there is still so much I don't understand. Would you care to make any comment on the settings for your MoI obj file save when importing into Carrara as per the attached please.

Hi Brian, well one thing that is difficult is that each program may have its own unique terminology.

Like for example in your dialog there I don't really know what the difference is in Carrara between a "Facet Mesh" and a "Vertex Primitive".


Sometimes the auto position and auto scaling can create alignment problems when you want to import pieces from several different files. Basically if each piece gets scaled to the same uniform size, relative sizes between each piece will get lost. So sometimes you might want to un-check "AutoPosition" and check "Disable Auto-scaling". But this is not likely to be an issue when you are importing just a single file to work on.


The "Map OBJ Y to Carrara Z axis" should only be used if your objects seem to be coming in rotated 90 degrees from the original. If they are then flip this checkbox.


Assume UV Coordinates are Between 0 and 1 - that should be checked, MoI does export UV coordinates between 0 and 1.


I would say the "Create one Object per Group" you want to have on, that will help get your pieces separated so you can assign different materials more easily.


- Michael

Thanks Michael.
Thats all been a great learning curve for me. I think I have a much clearer understanding of a lot of app file interrelationship problems that have worried me in the past.
Strangely, the Map axis option does have to be checked for MoI .obj files.

The Facet Meshes option is very odd. You then have to convert the items within Carrara if you want to work on them in the Vertex Room!(Which can be slow) I can not see a benefit.

So much I learned. MoI Obj saves is great. Thanks again
Brian