Handling huge CAD files?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
  06 June 2013
Originally Posted by Hoja: That seam you show may be perfectly valid and watertight.
It's merely not what Mesh Modellers would consider a particularly nice mesh.
You are saying that showcase indeed manages to come along without triangles and without Ngons while sticking to the Nurbs patch layout. I wonder how this is possible, as industrial production grade CAD may consist of myriads of patches. Keeping all existing seams, while being sufficiently accurate as well as adaptive in density - all this without using a single triangle or Ngon seemed like a miracle to me.

Of course that patch configuration is can bet watertight, showcase creates triangles not sure where i said it didn't. What showcase does really well that nothing else that i have seen does is the actual topology whilst it is tri's it doesn't create any long thin stripes, it doesn't create nasty n-gons its is adaptive.

Whilst it gives you a tri mesh its a very nice tri mesh that produces no rendering artifacts.

The trial version is 7gig and i don't have copy so i can't convert it for you :/ but you should give it a go if you deal with CAD data every day its rather nice.
__________________
Vizual-Element | Automotive Superstore
 
  06 June 2013
Originally Posted by instinct-vfx: The problem many tesselators have is not topology, but not beeing watertight.

Thorsten,
I am not sure if you are aware that in every Nurbs application there have to be polygon meshes for everything which gets displayed. As soon as you drag up a sphere in Alias, Solidworks, Catia, Siemens Nx, Rhino etc - together with the Nurbs automatically a polygon mesh is getting created - always. If there was no polygon mesh inside these apps one could not use a shaded display but only work in wireframe view. Therefore CAD apps carry double geometry with them at all time, but the mesh is only a display helper.

All native rendermeshes in each Nurbs Modeller should be watertight as soon as the underlying Nurbs model is. It is unfortunately often not what a Subdivision Surface Modeller would call a really fine mesh but it's closed and welded and all.

When one exports a mesh from any Nurbs package it is the render mesh what gets used. One can fine tune it with more or less control. Solidworks only gives you a density slider, Rhino has decent controls but one needs to know what one is doing, MoI even allows for an Ngon based remeshing. No package creates an all quad mesh even with proper loops but output should be watertight, if it's not the underlying Nurbs model will typically have issues too.

As soon as one instead exports to a Nurbs exchange format like step or iges it's a completely different story. As Nurbs are far more complex stuff than say a SubD-Mesh data interchange often causes issues. What the source CAD program calls a perfectly exact Nurbs boundary condition may cause a gap in the target program which got chosen for remeshing. It doesn't mean that one program is indeed more exact than the other but algorythms differ and may cause problems in the Nurbs geometry. Of course there's exchange formats and very expensive dedicated third party exporters.
But things may go wrong. If there's even subtle errors in Nurbs - they will always get transferred to the render mesh. When Showcase is so successful in mesh conversion it mostly will have to do with good Nurbs importers and powerful healing algorythms, not so terribly much with the mesher itself.

The seam Kabab posted would be ok when both the source application and the target application support Ngons. If the target app only does Quads and Triangles the Ngon would get triangulated. If the Ngon seam apprears unwelded in the target application that's not directly a problem of the mesher.

Last edited by Hoja : 06 June 2013 at 08:02 AM.
 
  06 June 2013
Yes i am aware that these applications have to carry a polygon mesh with them. That does not mean this is always a perfectly tesselated, watertight mesh. This is not something as trivial to do as it might seem. And the exports are fucked up in pretty much any case i have seen. I am simply talking from experience and the results. I am NOT talking about ngons and i am NOT a SubD Modeller by any means. I am expecting Tris, and i would not have a problem with ngons IF they are closed. The issue i am referring to are gaps, NOT NGons.

BTW, the reason that this is bad is, that with raytracers chances are that rays hit that gap no matter how small it may seem. This is most likely not so much an issue with rasterization i guess.

Regards,
Thorsten
 
  06 June 2013
Hmm, this does not match my own experiences. Open or invalid meshes from fine Nurbs may occur but are extremely rare. The cause is, I tend to say always errors in the source Nurbs model. Whenever a piece of geometry meshes badly it is time to inspect the Nurbs.
 
  06 June 2013
Here's a quick sample of the issue. This is the sample you posted imported with Max's Standard STP import to show the gaps. I selected the additional vertex as per the ascii from karba.



The problem that leads to this is, that the adjacent patches cause the tesselator to require different amounts of subdivisions by the rules provided (edge distance, angle distance or whatever criteria are set/enforced). Solving this is FAR from trivial and showcase usually excels there. Even if built in tesselators are up to par there (which i doubt honestly), the exporters fail miserably. VRML? In this millenium still. Really? OBJ? brrr. Note that this might not hold true for all CAD apps and versions, but it does for the major ones i had to deal with.

Regards,
Thorsten
Attached Images
File Type: jpg Screenshot.jpg (55.6 KB, 48 views)
 
  06 June 2013
Originally Posted by Hoja: When one exports a mesh from any Nurbs package it is the render mesh what gets used.


That is not quite the case. If you export a STL from ProE/Creo you get tris that can span large areas from one side to the other and can in some cases get very acute angles, like points of 5 degrees or less. Quite useless for rendering work. This is not the same mesh that is used in the shaded view. I'm not sure if this is some oddball STL standard from wayback.

I agree about errors in meshes being tied to errors in the nurbs data. Open edges in IGESs imported into Rhino is an example. Having a strategy in place to easily break out parts and areas for joining is needed to takle the IGES in Rhino. I have found Solidworks exports some nasty surfaces, the trims sometimes dont import well, normally on revolved surfaces of all things.
 
  06 June 2013
I've found the display meshes from most CAD apps are not always of a suitable quailty for high quality rendering.

Someone just needs to post a screen grab of a showcase mesh to bad no one has it installed.
__________________
Vizual-Element | Automotive Superstore
 
  06 June 2013
Hey guys,
it's not as if I would not agree with a lot of your statements. Effectively you are looking at nasty meshes and as this is your work geometry that's what counts for you as visualizers. I see that. My point is that you might look for the source of errors in the wrong spot.
Imo a lot of errors occur either already in the Making or in Transfer of Nurbs - these errors then inevitably get inherited by the mesher. In Thorsten's example I would heavily doubt that the surface data in the step file was read in correctly, hence the errors in the mesh. With Rhino I can export this file out in a handful of Nurbs formats and import back - meshes on that wonky thing are all valid.

There can not be a question that a lot of meshers in MCAD programs are far from optimized for slim and render optimized output - the inherent patch structure in CAD meshes alone is badly in the way for any advanced UV-Map creation. But I bet 99,5% of them are closed. Having to use completely triangulated.stl 's to at all output a mesh in Creo (is that really the only option?) seems like a joke though.
It certainly is not the internally used rendermesh. Then again I would not see why one needed anything more modern than .obj. for as long as CAD meshes don't support a single feature of more modern formats. There's some transfer aids available, such as between Solidworks and Modo, but you'll know that.

My reason to at all chime in was interest in the Showcase Mesher. From what I could gather thus far it seems to be a capable but conventional mesher combined with powerful Importers. These might have support for various widely used Geometry kernels built in.
 
  06 June 2013
Originally Posted by Hoja: My point is that you might look for the source of errors in the wrong spot.
Imo a lot of errors occur either already in the Making or in Transfer of Nurbs - these errors then inevitably get inherited by the mesher. In Thorsten's example I would heavily doubt that the surface data in the step file was read in correctly, hence the errors in the mesh. With Rhino I can export this file out in a handful of Nurbs formats and import back - meshes on that wonky thing are all valid.


Hm. Well the example was the sample you posted. So i assumed it would be as correct as it gets. I don't see why the tesselator would be the wrong spot tho. If i have a set of stp files, and showcase gets it correct in all aspects (joining, merging into objects by layers/mats whatever, great watertight mesh) and other tesselators/importers don't, then i'd say the issue is the importer, not the source.

Regards,
Thorsten
 
  06 June 2013
Quote: Hm. Well the example was the sample you posted. So i assumed it would be as correct as it gets

That's exactly the aspect I seem not to be able to communicate. There is no .step which is as valid as it gets. Or iges, or .sat or whatever Nurbs - exchange format. Doesn't exist. Although Rhino re-imports that step with no errors there's just perfect conditions given that Max fails.

This .step can only be read into another program flawlessly when the other program either uses the same geometry kernel (such as Parasolid) or both programs follow very strictly the given idiom of an exchange format (in my case step 214 automotive). Some programs initially import with errors but have powerful tools to "heal" the imported geo. Essentially these healing tools makes the import geo conform to paradigms of the target app - when sent back the source app will likely fail importing properly. The clearly best option was a translator which was specifically created in collaboration of programmers of source app and target app.

I'm not saying that exchange formats fail miserably, but there's indeed great chances that some things go wrong, especially when exchanging complex or poorly modeled stuff.

Last edited by Hoja : 06 June 2013 at 11:28 AM.
 
  06 June 2013
There are certain nurb topologies most converts don't handle well, showcase seems to do well with anything.
__________________
Vizual-Element | Automotive Superstore
 
  06 June 2013
I dont have the time right now. I will give this a go tonite in showcase, and i am shure showcase will create a watertight mesh of the same input. I don't know if this is because of the same kernel beeing used, but i fail to see how that would be possible if STEP files from different originating CAD systems all work flawlessly mostly. In addition STP seems to be way more robust than native formats. I thought this was due to native formats not beeing as stable across versions etc. e.g. CATIA files might loose trims etc, whereas step usually just works.

And when on a project i honestly don't care why showcase works and others don't. I'd just just it because it does
 
  06 June 2013
Hoja, my example of STLs from Creo was in response to you saying mesh exports are just the display mesh - which is not true.
 
  06 June 2013
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
__________________
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 03:49 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.