From Steph
Seems all Normals of this object are "inversed" (wrong way in all progs) !
and UV unfolding some anarchical!)

file 3dm linked follow

As far as i know MoI does not generate UV coordinates so that's why you see just the UV pap. :) You have to do the uv mapping in your favourite application.

I imported the file into Blender and had also inverted normals. I justt turned the normals to the outside.

MfG
sk2k

@sk2k
And have you succeed the UV mapping without problem with this file?

I had no problem with the unwrappingt. I only tried a simple cubic uv mapping and had no problem with it. I do not have them time now to try other methods.

What's exactly the problem with it and what program do you or Steph use?

Edit: I used Ultimate Unwrap 3D.

MfG
sk2k

Hi Pilou, the problem here is that the object isn't a completely closed solid, even though it looks like it is.

There appears to be some problem in join where some edges did not get glued together, I'll see if I can find out why.

The UV unwrapping is normal for MoI's current output. MoI currently outputs UV coordinates where each surface has UV coordinates that span the entire UV square. So what you are seeing there are the meshes for each different surface in that object stacked on top of each other.

At some point in the future I should be able to update this so that each surface gets a separate UV square instead of only all of them on top of each other, but I won't be able to do that for V1.

- Michael

Thx for precisions!

Hi,

unwrapping works also in Blender.



Maybe Steph should write a Hyperion exporter for Blender? ;)


Hyperion looks interesting i hope i can create scene walktroughs with it. I think i will try it.

MfG
sk2k

Thx for the try
And tell me if the Hyperion is an easy prog :)

Hi Pilou, I see now that there isn't a problem with join - that object is not a solid because the interior surfaces have been deleted (or were never created), leaving it an open surface instead of a closed solid.

If this was created as a closed solid, it should then export with the expected normal directions.

- Michael

Hi Tony, that is cool that Blender unwrapping works.

Did you do that unwrapping after applying a new cubic mapping, or without applying any new mapping?

MoI does export UV coordinates from its meshes, but the way it works is each surface get UVs for the whole texture, so it is basically like the texture image is replicated to each surface instead of each surface having its own smaller part of the texture map.

I was wondering if Blender was able to automatically take MoI's overlapping UVs and build a single larger "texture atlas" from it, or whether that was a result of applying new UVs.

- Michael

@Michael :Transmited to Steph :)

Some explanations from Steph :)
Objects are optimized so some surfaces are erased because not necessary when other objects are embedded inside it
In real time each polygon count :)
If a closed surface is good normally when open it direction of normal must be keeping (?)
During modelings of some new objects (in Moi )some curious strangeness things appear
boolean don't want work or inverse them (diff become union), chamfer don't work but filet yes (for a same object)...

And yes C4D can makes UV :) (see image follow)
(or works upon normal) But one more time it's more effective if Moi can make UV (or normal) from the Nurbs Export Obj because when you have 100 objects to remake by hand
it's some painful :)
And Auto UV like Zbrush are not practical for toshop for example
Ps @Sk2k : and sorry but Plug for Blender to hyperion are not planified :(

> If a closed surface is good normally when open it direction of normal must be keeping (?)

Normally it does work this way - I mean that if you have a closed solid and then delete or extract some faces, those faces should retain the same "outside" direction as the closed solid.

However, in this case the surface-of-revolution detection that I added to fix his last example is causing the problem for this model. The bottom part of his model is a trimmed part of a surface of revolution, a cylinder. The surface-of-revolution code is detecting this and orienting the normals outward from that trimmed cylinder piece, which is incorrect in this case. I will update the surface of revolution code to only work if the entire object is a surface of revolution around one common axis, not if the revolution is only one part of a larger assembly like this.

Once I fix up that, then this piece will work properly.


> During modelings of some new objects some curious strangeness things appear
> boolean don't want work or inverse them, chamfer don't work but filet yes (for a same object)...

Sounds strange... It's very difficult to guess what might be going wrong without seeing any example models.


> But one more time it's more effective if Moi can make UV (or normal)
> from the Nurbs Export Obj because when you have 100 objects to remake
> by hand it's some painful :)

I'll also add this to the list of things to work on in the future. It is not very easy to add it quickly because to do a good job since different sized surfaces should take up sizes in the UV map proportional to their area, so that a little tiny corner fillet piece does not have the same number of pixels as a large plane.

I'm basically already over the time that I wanted to spend for finishing up version 1.0, so it is not likely that any major new features requested at this time will make it into the 1.0 release, they will generally have to wait until the next version. But it is still very helpful to hear the requests since it helps me plan for the next version, it will just be a while before some of them will get acted on.

- Michael

Hi,

@MichaeL
sorry for my "late" answer. :)

I just used the standard unwrap command without doing anything before. With smart unwrapping in blender you can achive a better result. But if you want better results you should do some tweaking (maybe assigning seams) before unwrapping. :)



MfG
sk2k

Thx for the explanations and keep the good work :)

From Steph again
Curious bug ! (?)
Bug 1 Revolve has given these artefact under
but when you copy past the section and make again a revolve all works!

Bug 2 Impossible to make a boolean diff !
but when you load it all works!

It was not at the begining of a session, and no file/new

So some difficult to repeat the bug and found it!
Seems a sort of "refresch" don't work (?) or some code stay inside the prog (?) or memory managment failed (?)


Not a bug
Fillets block on construction line!

An automatic function closing curves / Surfaces ? (like "planar" but for any curves :)

Hi Pilou, I have finished the fix for the earlier one now, so that surfaces of revolution are handled properly and it will not attempt to flip an object that has a surface of revolution inside of a larger assembly. This corrects the normal direction of that open surface that you attached earlier, this will be in the next beta.


> Curious bug ! (?)
> Bug 1 Revolve has given these artefact under
> but when you copy past the section and make again a revolve all works!

This type of artifact near the pole area usually means some kind of alignment problem with the axis, where the endpoints of the revolved surface are slightly separated or overlapping each other instead of merged into one common single point.

The problem here is the profile curve is just very slightly above the origin in z, if you zoom in tightly to the front view you will see this gap:



That is only a small distance (0.0008 units) above, but still above it... It's large enough to cause the alignment problem.

What happened here is the revolve with the artifact in it was created by snapping the revolve axis to the origin or the grid, which is slightly off from the endpoints. When Steph tried it the second time after copy/paste, he probably snapped the revolve axis using endpoint object snap which then would produce the cleaner result.

I should probably do something like automatically move the endpoints of the profile curve to be directly on the axis if they are within a very small distance like this. That would fix this problem up automatically.


> Bug 2 Impossible to make a boolean diff !
> but when you load it all works!

Hmmm, thanks for sending this. That one is going to be hard to figure out since the problem doesn't repeat anymore. Maybe I will be able to compare it to other reports later on and see some kind of pattern.


> Not a bug
> Fillets block on construction line!

Yes, this is a limitation of the current fillet engine. Fillets won't cross an edge boundary like this. I hope that this will be improved in future versions of the geometry library that I am using.


> An automatic function closing curves / Surfaces ? (like "planar" but for any curves :)

This is the type of thing that an "N-sided patch" typ[e tool can possibly be used for. But unfortunately that one is not currently working well enough, it's another one that I hope will improve to work well in a future version.


Can you ask Steph if he has run into any program crashes while using MoI recently?

Thanks!

- Michael

Thx for the explanations!

< any program crashes while using MoI recently?
No and he has 12 --15 progs running in the same time :)

new bug during the export Obj (3dm linked)! (enable shaded for see it)

Hi Michael,
I can confirm that this does appear to be an intermittent bug -
Here's what I've noticed:
- MoI will refuse to do a boolean op, doesn't seem to matter which op is being attempted.
- It only happens after I've been using MoI for 2-3 hours straight.
- The forms being operated on don't seem to matter. Extruded forms, swept forms, primitive solids, all the same problem.
- I've had this bug pop up maybe 3 or 4 times over the last few months, so it's a fairly rare bug, and doesn't seem to have any consistent pattern of when and why it happens.
The solution that i've worked out is to save the file, close MoI, restart MoI, load the file, and then the boolean op I'm attempting will work fine.
Hope this helps!

Paul