Hi Michael,

So far I've only used IGES files that have been created in ZSurf4 & they've only been as a textured type surface.
So far this process has worked extremely well, allowing me to Trim those IGES surfaces & pretty much do anything I wanted with them.

Now that I have 3D-Coat, I decided to try making a texture within it & Export that out as a OBJ file.
My plan then was to Import that 3DC created OBJ file into Rhino & then Save it out as a IGES file for use in MoI.
Great plan if it'd work, but unfortunately it didn't because Rhino wouldn't allow the solid object to be Saved as an IGES file?
But due to my total lack of experience with the IGES format, I'm not really sure why it didn't work or even if it's possible to achieve what I want in Rhino4?

I did notice when saving the IGES that there's a drop down list of various different output choices, but I just used the Default?
With all those choices is there one that I should be using for this to work, especially if I'm then wanting to Import it for use in MoI??

Hope all of that makes sense.
Let me know if you'd like the OBJ file or perhaps the R4 3DM with it's Saved in.

regards Colin

Hi Colin, well here you're running into an issue that's more than just translating between different file containers, you're also trying to translate between very different data types.

The data that is generated from 3D-Coat and saved into OBJ format is polygon mesh type data, where there are not any curved spline surfaces in the data, instead the data is made up of a whole lot of little tiny flat polygon facets.

IGES format on the other hand, is meant to contain smooth NURBS surface data, where surfaces that look like they are smooth are actually made up of larger spline patches instead of a whole lot of little flat facets.

MoI is only designed to work on that kind of NURBS surface data and is not set up to work on polygon mesh data. So it's not really feasible to export from 3D-Coat into MoI, you are using a much different kind of data there in 3D-Coat than what MoI uses.

It's kind of like saying you want to make a graphic in Photoshop and then bring that into Microsoft Word to spell check it, or something like that.


There are some tools you could use to try and recalculate the data into NURBS form, but that can be a tricky reverse engineering process.

If you have a relatively small number of facets, you could use the MeshToNurb command in Rhino to convert each facet into a trimmed NURBS plane. But be aware that this behaves poorly for converting a very dense mesh, as NURBS are designed to have smooth surfaces as larger spline surfaces and not as a zillion little fragments.

If you have something that is supposed to be used as the control hull for a subdivision surface, then you could try using the T-splines plugin for Rhino to convert it to a smoothed NURBS result.

Otherwise, you could try some of the fancy and expensive reverse engineering solutions that fit NURBS surfaces to polygon mesh data, check out this previous post for some links to that:
http://moi3d.com/forum/index.php?webtag=MOI&msg=2469.3


Also see here for some previous discussion:
http://moi3d.com/forum/index.php?webtag=MOI&msg=3332.9

 

It works much easier to start with NURBS and then export to polygons - that would be like starting in MoI and then exporting into 3D-Coat, instead of the other way around like you are trying to do here.

That's because MoI can generate polygon data from NURBS data by producing all those little facets. But starting with a ton of facets it is hard to go back the other direction. It's kind of like how you can take apples and smash them up into applesauce, but if you start with applesauce it is pretty difficult to make apples from it.

So for the most part that opposite direction of starting in 3D-Coat and then trying to go into MoI from there is not really feasible.

- Michael

Hi Colin,

If you want to, I could try to convert the OBJ file into MoI for you. I have had success with some other cross-software (as I call it) conversions of OBJ files into MoI. If you like, you can send me something non-proprietary to do a test first. PM me if interested. I can give you the details of the process I use. Kind of a long way around the bridge solution, but it has worked. I too use zsurf. Good stuff!

Let me know.

Michael T.

Hi Michael,

Thanks for that explanation, it gives me the answers I needed to know.

For most of my jewellery work I can pretty much manage to do all of my modeling within MoI & only move out of it to use Rhino as required.
It's just been those few odd designs that require some form of a texture that have caused me any real grief...
...so by using either a ZSurf4 IGES file or Rhino's "HeightField" to get a NURBS surface, those usually solved the problem.

I think what I did was fall into the trap that having successfully used IGES files before with a texture, that it was going to be a "magic bullet" for anything with texture...
...I can now see why that wasn't ever going to work for me.
As my understanding of all this stuff slowly grows, I'm starting to think I'll need to consider getting T-Splines as part of my workflow.

regards Colin

Hi Michael T,

Thanks for the offer.
Here's that OBJ file out of 3D-Coat.
It's nothing overly fancy, just something that I was trying out to see if the process would work.

Sadly my use of ZSurf4 is still rather limited due to my lack of fully understanding all of it's Sliders & Settings.
I'm pretty much just using the Default settings & go from there into MoI.
I really do need to find out more on how to use it better & to it's full potential.

regards Colin

Here's a screen capture of what the OBJ looks like in Rhino.

Hi Colin,

> As my understanding of all this stuff slowly grows, I'm starting
> to think I'll need to consider getting T-Splines as part of my
> workflow.

T-Splines could definitely have a place in your workflow, but I'm not so sure it would be the right tool for the kind of texture that you are showing in that particular OBJ example file above.

With T-Splines you are going to be working with a cage of control points, and to make it easier to control things you'll probably want that cage to be somewhat sparse.

The thing that is nice about T-splines (and sub-d modeling in general) is that everything within the cage stays very smooth and melty looking, even if the cage does things like have a branching structure with things dividing and separating.


But if you want to have a dense level of "high frequency" texture like your example above, that is probably something that will work best to apply only in 3D-coat or ZBrush as more of the final stage in your process before you export to an STL.

So your process might be more like build some basic surfaces for the overall general shape in MoI, then convert into polygons, bring into 3D-Coat and apply detailing and textures in there, and from 3D-Coat you go directly out to STL.


For rendering purposes, often times those kinds of details are not really modeled at all and applied by shaders and textures which modifies shapes just at render time.


That kind of high density very bumpy texturized stuff just does not fit very well with NURBS, so once you get to that stage you are kind of in some different territory at that point.

But NURBS works great for doing "broad and smooth" kind of shapes that come together from 2D profile curves.


- Michael

Hi Colin,

It will be sometime this evening when I can get around to it, but I should have something back to you before 04/14.

Thanks for letting me have a shot at it :-)

Michael T.

Hi Michael T,

No prob's, only when you've got the time, there's no need to hurry.
Looking forward to seeing & learning how you tackle it.

regards Colin

Hi Colin,

I had a memory issue when I was writing the IGES file. Is there a file you can make with a less dense mesh? Sorry about that. I am limited a bit on hardware.

Michael T.

Hi Michael T - even with the best hardware available, that process of converting every single polygon in a dense mesh into a trimmed plane in a NURBS solid is going to very easily have problems.

It's a fundamental mis-match between how things are designed. With polygons, it is intended that curved surfaces are approximated with a whole lot of little facets. With NURBS it is intended that curved surfaces are represented by large smooth spline surfaces.

You shouldn't try to make a polygon mesh model using only 1 polygon for what is supposed to be a curved surface, and you shouldn't try to make a NURBS model using a zillion little facets for what is supposed to be 1 curved surface.

In some simple cases you may be able to force the issue, but you should not expect for it to work well in general, it's not using the different structures in the way that they are intended to be used.

- Michael

Michael,
Along these same lines, it doesnt appear styles (or colors) are going with step and iges files. Is this intentional? am I missing something or is it something you plan at some points. My CAM package uses the Harmonyware translators also, and we have the same issues.

Hi Burr, actually colors are being written to IGES format currently.

For example I made this setup in MoI and then exported to an IGES file:



That IGES file then loaded into Rhino looks like this:



Loaded into ViaCAD looks like this:



Loaded into CoCreate looks like this:



Which program are you trying to import the IGES file into? Are you sure that it supports reading in colors?

I'm not quite sure about STEP, I'll take a look at that.

- Michael

Hi Michael,
I did make a mistake. The program I was refering to is BobCad and it doesnt read in the colors.

The reason (and mistake) I made with MoI was I did a test and didnt think it was writing the colors in.

My test was a cube and I gave each of the faces a color and exported, then brought it back in and the cube was the default color! I thought it was not writing colors.

On further review, since you showed it is, I recreated the cube with colors. As seperate surfaces, the cube exports out and back in with all the colors. If I join it back to a solid, then export and import back in, the cubes entire color is that of the ground plane color! (apparently in my tests, that must have been the face I left at the default color) So on import, the entire cube was the default color.

Anyway, if I leave the surfaces seperate, the colors are going back and forth.

Hi Burr, yeah several different things relating to IGES may not be expecting to work with a single solid getting joined up made up of multiple different colors within it.

Currently when MoI writes out an IGES file it will only write out the single color assigned to the parent object and not colors for individual sub-objects within a joined solid.

Maybe I can look at tweaking this in the future but I'm not so sure that you're going to find it widely supported to get a solid joined result that still has those different colored faces within it.


Having faces with individual colors within a single object is more widely supported in mesh formats so that does work fine with OBJ or LWO exports.

- Michael

Hi Michael,
Yeah, it's not something needed I found in a workflow of any kind. Only that I made the mistake and was thinking MoI wasnt writing those colors out. Now that I know it does, I am clear on what is happening.

Thanks again.

Hi Michael T,

Here's another version with the mesh reduced to about the maximum 3D-Coat will allow.
Hopefully this will allow you to do what you're after with it.
But if you need something else with regards to this, then maybe it's best to PM me from here on.

So based on what Michael G has already previously written, I now understand that what I wanted to do wasn't really practical as a workflow.

I'm seeming to find that the style of models I get asked to make, draws me into something that requires a combination of CAD style NURBS & Sub-D work.
I already know what the perfect solution is...buy myself ClayTools or FreeForm from SenAble. http://www.sensable.com/index.htm
But as I'm now doing work more as a "Hobbyist/Jewellery Modeler", I can't justify spending anywhere near that kind of money, even for their basic package.

So I'll just keep battling along trying to develop myself alternatives that'll give me a good workflow for those oddball & sometimes difficult jobs I seem to score.

regards Colin

Michael,
"I'm not quite sure about STEP, I'll take a look at that."

According to the help file in Solidworks, STEP AP203 does not handle colour information. Whereas STEP AP214 does handle colours.
Of course there are a bazillion STEP APs so I don't have a clue about the rest, all I know is 203 is very common and 214 is sort of common too.

Thanks Colin for the new file. I'll check it out and let you know what I come up with.

Thanks Michael G. for the clarification regarding nurbs vs. polygon geometry treatment. I only use these crossovers for reverse engineering purposes for non-exact geometry extractions.

Thanks again,

Michael T.

Hi Kevin,

> According to the help file in Solidworks, STEP AP203 does
> not handle colour information. Whereas STEP AP214 does
> handle colours.

It sure would be nice if STEP was not as confusing as government bureaucracy tax forms... :)

Just to make things a little more confusing there is apparently a "second edition" of AP203 that increases overlap with AP214: http://en.wikipedia.org/wiki/ISO_10303



I seem to remember that there was actually a bug fixed in the HarmonyWare STEP exporter for color information that was causing NX4 to crash when it read it in, so at least at one point colors were going into STEP files out of MoI but I'm not sure if this has possibly changed with an update of the HarmonyWare libraries.

- Michael

Hi Colin,

I finally generated the MoI file from your OBJ file, unfortunately even zipped up it is over 31MB. I'll see if I can get it smaller to post here.

Regards,

Michael T.