Just a quick update - I've got good quad support for OBJ export working now, I've attached a sample obj file here.

I'm going to try to squeeze in a couple more things, like ngon support for planar surfaces, and maybe some mesh display options before releasing it. Shouldn't be too much longer though.

- Michael

Loaded with any special regulates

Seems only circular surfaces resist :)

On Wings3D I have some curious external edges

On Anim8Or only curious inversed normals on the Cone :)

Seems all progs have not similar motor engine of OBJ format :)

Sounds good:-)
I'll try it as soon as I can with Softimage|XSI (On monday I guess)

N-gon for planars would be good too, then we don't get those messy cylinder caps etc.

Another thing that would be very good is merged vertices (with good tesselation) along fillets, but I guess that's a tricky thing to code.

> Seems only circular surfaces resist :)

Hopefully not for long, n-gons should clean those up too.


> On Wings3D I have some curious external edges

Yes, I get those in Wings3D even when exporting using the current beta release that only has triangles. I also tried exporting that shape to .obj from a different program and the problem in Wings3D repeated. Seems like maybe a bug in Wings3D when reading an .obj that has more than a certain number of points in it?


> On Anim8Or only curious inversed normals on the Cone :)

I think I have fixed this - it turns out that the cone was outputting quads with 2 points pinched together at the top. Thanks to your report, I have fixed this so it will put a triangle in that case instead, which cleans up some problems like this.

- Michael

> Another thing that would be very good is merged vertices (with good tesselation)
> along fillets, but I guess that's a tricky thing to code.

Could you please explain this one a little bit more?

The tessellation should already be producing matching vertices between surfaces that are joined to each other, including fillets...

- Michael

Here's a sample of ngons on planar surfaces. But I still have some cleanup work to do for the display, it will be a couple of days yet.

- Michael

It's ok for Shade & Blender & Anim8Or & Amapi 6.1 always curious on Wings3D for the spiral!
Ok for Steph with C4D have you some examples with more complex objects geometry?

Can you put the 3dm file for the orientation of axes, and Pivot World / Object or possibility to export with own Pivot/Object ?
Bon courage! :)

Xsi imports them fine.
The only problems i see are with the fillet box edges highlighted in red. For some reason those remained tri's.
The blue edges are disconnected but not a problem since that can be fixed pretty easily

good deal!!... at least these obj's are workable.
BTW. have you tried exporting a slightly more complex shape? maybe a booleaned sphere with a fillet edge.

cheers!

-isaac

Hi Skello, thank you for trying it with XSI.

> The only problems i see are with the fillet box edges highlighted in
> red. For some reason those remained tri's.

If you count the vertices along that fillet edge, there are 9 points along one side, and only 8 points along the other side. There just isn't any way to connect 9 to 8 using only quads.

Maybe in future versions it will be possible to improve this by trying harder to get the same number of points generated along all of those edges. It will probably be quite a while before I'll be able to work on improving that though.

It is very difficult to get an automatic meshing that does things as intelligently as a person would doing it by hand... I'm not sure that it is ever going to be 100% there. But at least this is a significant step towards far more clean and workable output than before.


> BTW. have you tried exporting a slightly more complex shape? maybe a
> booleaned sphere with a fillet edge.

I should have the next beta ready tomorrow, so you'll be able to try it yourself! You can expect to see a lot of triangles in trimmed areas (like with booleans) though. Anytime there is an irregular number of points that need to be connected up to each other you will see them.

- Michael

>Maybe in future versions it will be possible to improve this by trying harder to get the same number of points generated along all of those edges.

Ah! that explains it. I was under the impression that the edges would have the same number of points since they were derived from a fillet with a fixed radius.

>I should have the next beta ready tomorrow, so you'll be able to try it yourself!

cool ! look foward to playing with it tomorrow :)

-isaac

> Ah! that explains it. I was under the impression that the edges would have the
> same number of points since they were derived from a fillet with a fixed radius.

That's certainly not an unreasonable impression... I explored it a little bit to see why, and it turns out that those fillet corners have underlying surfaces that are slightly larger than the edge boundary, they have trim curves on them that trim them back to the piece that you see.

Having the underlying surface larger was affecting the meshing, because part of the meshing involves subdividing the surface, in addition to breaking up the edges.

I was actually able to fix this up by shrinking the underlying surface right up to the trim boundaries when doing the meshing, this makes all those pieces have a consistent structure and that particular filleted box is now all regular quads along those edges. So that's another little step forward for cleaner output.

I was thinking earlier today that it should be possible at some point to output ngons along trimmed areas such as booleans, sort of by doing trimmed quads as ngons... However this may be a bit difficult to do so it might be a v2 thing...

- Michael

Amapi Designer likes it just fine. Poser has one small
problem..... it sees a 'seam' or 'wrinkle' on one side of
each circle-based shape. (Cone, cylinder, sphere.)

>>Amapi Designer likes it just fine. Poser has one small
>>problem..... it sees a 'seam' or 'wrinkle' on one side of
>>each circle-based shape. (Cone, cylinder, sphere.)

Same here with various software (Blender, Modo, Vue...). Seems to be a problem of unmerged vertices (that share the same coordinates) as a "remove doubles" or "merge vertices" operation fixes this.

Schbeurd

> Same here with various software (Blender, Modo, Vue...). Seems to
> be a problem of unmerged vertices (that share the same coordinates)
> as a "remove doubles" or "merge vertices" operation fixes this.

Yeah, points along a seam are not shared. This will cause some programs to display a crease there if they calculate new smoothing information manually. But if they use the smoothing information ("vertex normals") that is actually stored in the .obj file you wouldn't see the seam there.

I don't automatically merge the vertices there right now because that would mess up the uv texture mapping information which is also included in the .obj file as well...

I suppose that I could add automatic merging in as an option. Maybe it should be on by default if more people are expecting to have merged vertices than expect to have distinct uv texture coordinates along the seam.

- Michael

>Could you please explain this one a little bit more?
>The tessellation should already be producing matching vertices between surfaces that are joined to each other, including fillets...

Ah, that's my bad, then. I propably tested it without joining.

> I don't automatically merge the vertices there right now because that would mess up the uv texture mapping information which is also included in the .obj file as well...
> I suppose that I could add automatic merging in as an option. Maybe it should be on by default if more people are expecting to have merged vertices than expect to have distinct uv texture coordinates along the seam.

Interesting info here. So far I didn't try to texture one of my MoI models so I didn't notice that UV coordinates were included in the OBJ.
Now, what happens if I merge the vertices in another program. Will it create some mess in the UV coordinates ?
Anyway, merging as an option (selected by default or not) would be a cool feature.

Schbeurd

From Steph
Seems ngones resist a little bit :)

> Now, what happens if I merge the vertices in another program. Will it
> create some mess in the UV coordinates ?

Yeah, they'll likely be a bit blurry right along that seam. Imagine that you're wrapping a bitmap around a cylinder for instance. For the bitmap to come out crisp along the seam edge, there can't just be one UV coordinate there, one side needs to have a UV for the start of the bitmap, and poly from the other side needs to have a UV for the end of the bitmap, even though they are ending on the same location along the seam. It's possible that some software might be able to handle it better if they keep track of UV coordinates per polygon face instead of per polygon vertex though. Hmm, come to think of it .obj actually allows one to specify different uvs per-face like this (distinct from the xyz vertex location) so I suppose I can support it... I'm not exactly sure how well supported this is by most .obj importers though.

- Michael

> Seems ngones resist a little bit :)

It looks like there is an ngon in there along the top face.

Right now ngons will only happen along planar faces. The front face there is curved, not planar, so that's why no ngons in that spot.

I'm thinking of some other possibilities on generating ngons on non-planar surfaces, I might be able to give something a try...

- Michael

From Steph again :)
Your obj export works yet better than the Rhino and other progs! Bravo!

Just a little complaint ; The "scale" for C4D must be * 10
If you can intergrate a mutiply coefficient that will be cool :)
(some prog have their own scale unity system)

An another example of Ngones follow quasi perfect! :)