GMD Export Formats and Variations on KS Import

[HaroldL]

I have started a model of a Mountain Howitzer Model 1835 and noticed some tessellation issues when rendering in Keyshot.
As a test I exported the model out of Geomagic in the various file formats that Keyshot supports. I then imported them in to KeyShot changed the material type to Metal and took screen grabs of the resulting image.

Results:
It didn’t matter if I used the Live Link option or the Export option on the render tab or if I used File>Export to output the bip file the results in KeyShot all looked the same and IGES gave similar results. All with some noticeable tessellation on the curves when zoomed in.

STEP203/214 and SolidWorks part (GMD appears to export it as STEP but names it .sldprt), and Parasolid all gave the same messed up results.

I actually got pretty good results when I exported the file as STL and adjusted all the settings to the finest level. The import in to Keyshot took a little longer but the tessellation issue was reduce quite a bit.

As a disclaimer, I am using Keyshot 6 Pro but, unless 3DSystems has done some "inhouse" tweaking to KS, the results should be the same in KeyShot for 3DSystems.

Draw your own conclusions.

As for the STEP importer, Niko at KS Support told me

I checked with the responsible developer.
The issue with the STEP import lays within the third party importer used, as the issue is fixed we will include the update in the next version of KeyShot.
You will probably need a bit patience for this to be included in KeyShot.

Now, if only 3DSsystems would increase the tessellation of GMD.

 

[JST]

How long did you let it go on rendering?

Obviously some of them simply fouled up the geometry. The others seem to have visible pixels, which I assume is what you refer to.

The others should keep improving over time as the processing goes on up to what you set. I notice roughly the same amount of pixelizing on all points, but some pixels are "sharper" than others. The pixelizing will be a function of the resolution you select (I assume 6 is like 5, I have not downloaded 6 yet), but the pixel processing is something that goes on as the image is refined.

And, the pixels will continue to shrink in size as processing continues, up to the set resolution. If the resolution seen in the views is not the set resolution, then there is at least one more round of pixel shrinking to go.

Looking at it, I see you have a 961 x 722 pixel resolution, which is barely VGA quality.... You can set it higher if your display will handle it

 

[HaroldL]

The test was only to compare the various file formats that GMD would output and KS would import and to show those results.
I've been using KS since Hypershot so I know about render time. :roll:

 

[JST]

Well, there is render time, and there is basic resolution. Your complaint was evidently related to resolution, which is (as you know) settable.

Looking at the output PNG in very expanded form did not seem to show anything which was not explained by the basic pixel size of the image. Whatever you are looking for would have to be visible at the resolution of the image.

The versions that do have generally correct geometry appear to still have coarse resolution. AND it seems to be the SAME resolution in all of them. You did not mention what resolution you set to, which would presumably directly affect your issue with render quality.

The comment on render time was simply prompted by my observation that Keyshot seems to progressively render to finer and finer "pixelation" until it reaches the setting you entered. If you had (as recommended in the quicktips) set to a definite render time, it might not have completed to the finest resolution level set. Or, the resolution might have been set coarser and forgotten. Or the resolution may simply be already at max, and that is what you get.

 

[HaroldL]

. . . Your complaint was evidently related to resolution. . .

No it wasn't. If you go back and read my post you'll notice that I said nothing about render quality. The whole exercise was ONLY to compare the different formats that export out of GMD and import in to Keyshot and the screwed up geometry and tessellation that resulted in some of the files.

I used Snagit to capture the screen images so resolution doesn't mean a thing in that regard. Some images may have cooked a little longer than others but Snagit just got my screen resolution at whatever state the render was in at the time. I did not care about that.

As I also noted, Keyshot Support indicated that the STEP importer was a 3rd party importer that may or may not get fixed in time for the next update to KS.

 

[JST]

OK.

The only way that I have to see what you are talking about is through the medium of the PNG file. I can see obvious pixel limits in the pictures, and did not see anything that wasn't due just to that. Other than the wrong geometry, of course, which I just discounted.

For those who are interested, can you point out the problems you see (leaving aside the obvious ones where the geometry is wrongly rendered)? Maybe I am losing the forest in the underbrush......

Or was the point the wrong geometry?

To me the tesselation is the mesh size used to represent the forms. It SHOULD be such that it is not visible, and small enough not to be an issue within the decimal places used. Some approximations appear when you zoom in on circles etc. But those are graphical, and not necessarily the internal calculation meshes.

I suppose it would get to be an issue for mm level details on very large objects, where the 6 decimal places shown in GMD might represent fairly large detail only.

I'm just not seeing the result you seem to be talking about on the pics.

 

[HaroldL]

Ahh, To your point about indicating where the errant geometry is, here is a repost of my previous image with arrows pointing to the problem geometry on the handle and a screen grab of the part in GMD for comparison.

 

[JST]

yeah, I saw that, but didn't associate it with what you were talking about. It's pretty visually obvious something didn't translate, I didn't need the circles and arrows for that part, I thought there was another level of problem.

Those areas are really screwed up, either due to some export error, or???? It's SO gross, I didn't associate it with a tiling error.

Was that the actual issue in question, then?

I've seen that show up once in a while myself. Seems as if I shifted the view, zoomed, etc and the issue went away. Maybe a tiny dimensional change, don't actually recall.

I actually think there may be a pervasive issue somewhere in the GMD engine when it comes to curvature.

In fact, now that I think about it, some of the grossly goofy stuff I got when trying to model that crankcase seems as if it is related to your issue. Certain combinations of numbers seem to be bad... and tiny changes can totally change the way it shows up. I forget just what I did to get the crankcase to "go", but it DID involve some simplification of the curvatures. Now I am wishing I had kept notes. The simplifications were not bad for the model, they were actually probably closer to the original, I had some over-complex stuff going on.

All that I recall is that I changed details of how the surfaces were to meet. When I got done,the various edge lines were much simpler than when I started.

Yours do not look so bad, in fact it is crazy simple geometry, really. But maybe when zoomed in on them it may be that there is something going on. GMD really hates "cusps" in geometry, so if the curvatures do not always meet perfectly (from rounding errors, or whatever), then it can lose its mind.

I notice the problems are the intersections of the stem with the ball, and whatever that round deal on the back of the ball is vs the ball. Intersections of curves like that seem to have potential to confuse GMD. Kinda like the "cannot solve capping faces" that comes up all the time doing fillets.

The only thing you didn't specifically try was a BIP.... I assume that would be equivalent to the live link.