Import a IGES (*.igs) files in to Second Life

We can import almost everything we want. We can import Textures. We can import Animation. I have asked why not objects? I have not been told. I was told by a few people in SL that it would be unfair for people like me (A Mechanical Design Engineer) to be able to do this. I can say the same about Textures done by professional artist using high end programs I can not buy. We also have Animations done with Poser 5 that I do not have money for. I use Pro/E. Why can’t I import a IGES (*.igs) files in to Second Life? I think if this was added we could end up with higher level of skilled designs.

About IGES
________________________________________
A General Description of IGES
Products may be designed as either a two-dimensional, three-view drawing layout, or as a full three-dimensional model with associated drawing views and dimensions using a Computer Aided Design (CAD) system. The IGES format serves as a neutral data format to transfer the design to a dissimilar system. Translators, developed to the IGES Standard, are used to export a design into an IGES file for exchange and for importing the IGES file into the destination system.
The IGES Domain
"This Specification establishes information structures to be used for the digital representation and communication of product definition data.
The file format defined by this Specification treats the product definition as a file of entities. Each entity is represented in an application-independent format, to and from which the native representation of a specific CAD/CAM system can be mapped. The entity representations provided in this Specification include forms common to the CAD/CAM systems currently available and forms which support the system technologies currently emerging.
In Chapters 3 and 4, the product is described in terms of geometric and non-geometric information, with non-geometric information being divided into annotation, definition, and organization. The geometry category consists of elements such as points, curves, surfaces, and solids that model the product. The annotation category consists of those elements which are used to clarify or enhance the geometry, including dimensions, drafting notation, and text. The definition category identifies groupings of elements from geometric, annotation, or property data which are to be evaluated and manipulated as single items."
Quoted from Initial Graphics Exchange Specification (IGES) Version 4.0, NBSIR 88-3813, June 1988, pages 1-2.
IGES File Structure Overview
"The fundamental unit of data in the file is the entity. Entities are categorized as geometry and non-geometry. Geometry entities represent the definition of the physical shape and include points, curves, surfaces, solids, and relations which are collections of similarly structured entities. Non-geometry entities typically serve to enrich the model by providing a viewing perspective in which a planar drawing may be composed and by providing annotation and dimensioning appropriate to the drawing. Non-geometry entities further serve to provide specific attributes or characteristics for individual or groups of entities and to provide definitions and instances for groupings of entities. The definitions of these groupings may reside in another file. Typical non-geometry entities for drawing definition, annotation, and dimensioning are the view, drawing, general note, witness line, and leader. Typical non-geometry entities for attributes and groupings are the property and associativity entities.
A file consists of 5 ... sections, Start, Global, Directory Entry, Parameter Data, and Terminate. A file may include any number of entities of any type as required to represent the product definition. Each entity occurrence consists of a directory entry and a parameter data entry. The directory entry provides an index and includes descriptive attributes about the data. The parameter data provides the specific entity definition. The directory data are organized in fixed fields and are consistent for all entities to provide simple access to frequently used descriptive data. The parameter data are entity-specific and are variable in length and format. The directory data and parameter data for all entities in the file are organized into separate sections, with pointers providing bi-directional links between the directory entry and parameter data for each entity. The Specification provides for groupings whose definitions will be found in a file other than the one in which they are used."
Quoted from Initial Graphics Exchange Specification (IGES) Version 4.0, NBSIR 88-3813, June 1988, page 3.
As IGES data is in ASCII clear text, any desired means of transferring the IGES file may be used, from tape and floppy disks to Internet. For the latter, an Internet message type of "model/iges" has been registered with the Internet Engineering Task Force. In addition to CAD-to-CAD (or CAM) transfer, the destination may be a graphical viewer. A number of vendors of viewing tools and adapters may be found on the Tools page of this site. Some of these tools allow editing/repair of IGES files. A general purpose text editor may be used to edit an IGES file, however as the entities and file sections in an IGES files are "pointer linked," the use of IGES-specific editing tools is desirable.
Brief History of IGES
"In 1979 events took place that catalyzed the CAD vendor community to create the first national standard for CAD data exchange. Mechanical CAD systems were less than ten years old, and there were only a handful of products with any significant market penetration. Even at this early stage, users were overwhelmed by the inability to share data among these tools and with their own internally-developed databases. Frustration was evident at a fateful two-day Society of Manufacturing Engineers (SME) meeting in the Fall of 1979. On the first day, an attendee from General Electric (GE) challenged a panel of CAD vendors, that included ComputerVision, Applicon, and Gerber, to work together to enable a common neutral exchange mechanism.
The panel reported on the second day, and the wheels were set in motion to create an 'IGES.' Once the panel admitted that a common translation mechanism was possible, it was impossible to stop the momentum of the customer's enthusiasm and expectations. Applicon and ComputerVision agreed to open their internal databases, GE offered its neutral database, and Boeing offered the structure of its Computer Integrated Information Network (CIIN) database. Both GE and Boeing contributed their existing translators. A core team was formed that included representatives from NBS, Boeing, and GE. Team members had worked closely with each of the vendors on internal integration projects. This prior experience built the expertise and trust needed to craft a solution in a very short time, and neither vendor felt it gave an unfair advantage to the other.
Soon after, an open meeting was held at the National Academy of Sciences on October 10, 1979. Approximately 200 people attended to herald the birth of IGES."
Quoted from B. Goldstein, S. Kemmerer, C. Parks, "A Brief History of Early Product Data Exchange Standards," NISTIR 6221, September 1998.
Dr. Phil Kennicott offers the following recollection: "...the original work started as a result of the National Academy of Sciences meeting. That was when I told the Air Force man that, if Boeing would make Walt Braithwait (and CIIN) available, I would join in with [General Electric] Neutral Database."
A vignette on Initial Graphics Exchange Specifications (92K PDF file) was included in A Century of Excellence in Measurements, Standards, and Technology - A Chronicle of Selected NBS/NIST Publications, 1901 - 2000, David L. Lide, Editor; NIST Special Publication 958, January 2001, available from the National Technical Information Service (NTIS), #PB2000-107702.
A series of IGES milestones may be found elsewhere in this Web site. These milestones identify the versions of IGES, adding additional product properties, solid models, and new features. Application Protocols for Three-Dimensional Piping (ANS US PRO/IPO-110-1994) and Layered Electrical Products (ANS US PRO/IPO-111-1997) have also been approved to provide a uniform representation of these products using the IGES format and data entities.
One benefit of an open standard for product data has been the ability to entertain changes from the using community. This Web site provides the forum for communicating proposed changes and open review by all concerned. The resultant versions of IGES are then reviewed for publishing as ANSI standards. Each version has, and will, include those changes which have reached consensus by the reviewers. The approved changes are termed Engineering Change Orders, such as those found in the Current Version and Next Version page of this site.

there's already been quite a few posts about different 3D file formats and importing/supporting in SL... The big problem comes in because SL uses a completely different "modelling" engine than CAD systems... polygons/ faces are generated automatically based on the prim type, not imported from a file like a CAD model would be.

Do a search on the forums, u will find a buncha posts relating to this.

Happy modeling!

Arti

Fairness has nothing to do with it. The issue has everything to do with the streaming nature of SL. All machines using SL are able to construct objects quickly because all objects are made of the same building blocks. Every machine involved has pre-programmed knowledge of how to create a cube, a sphere, a cylinder, etc. Therefore the only information that needs to be streamed over the internet is where to put them and how to size them, which is a very small amount of data.

Were outside 3D models to be imported, that kind of compact description would not be possible. The full instruction set for how to create every single polygon would need to be streamed to every single client machine for every single object, which would take forever and then some.


Now that you have your answer, let me point out that the questions you are asking come up time & time again every time anyone with any modeling experience joins SL. At first, the in-world modeling tools seem childish, even silly, and you spend 90% of your time saying "If only I could import my Maya models, or my 3DS models, or my CAD models..." As you spend some time in SL though, you'll begin to discover that this "limited" tool set, which you find so silly at first, actually forces you to employ creative problem-sovling skills and techniques that you would never normally consider. As a result, you end up becoming a better modeler both inside and outside of SL.

To use myself as an example, outside of SL I'm a Maya person. I can atest that my poly counts per average model have gone down tremendously since I started using SL while the quality has gone up, and my texturing skills have improved a hundred fold. The same is true for just about everyone I know who is in the 3D field who uses SL. Quite simply, it forces you to pay attention to detail in a way you otherwise woudn't, and that process provides tremendous growth potential for you as a modeler. Give it a few weeks and you'll see exactly what I mean.

Yeah, what Chosen said....

I agree also, my texturing skills have increased exponentially since coming into SL...

I do mostly AutoCAD myself here. I just pretty much just miss the slice, extrude/punch, revolve, loft, and boolean commands available in CAD. Skinning would be a nice addition too but that's just wishful thinking for now... Aaah all in good time

Now I can see were that would be about right. I say about for one simple reason Textures & audio are not and that has to slow down the system as it is. You also have in 1.6 streaming video. If it is not a problem for Textures, Audio, & Vidio we can take a leap that it should not be a problem with Objects. Now we can also in the translation change every thing in to the standard objects.





Maybe for your job that would work. The big problem with saying that about Pro/E you end up losing more then you gain. Keeping Feature (poly) count down does speed regeneration time down and it will reduce file size. The problem it if stop caring about Size and time and look at reality you end up with a more robust solid design allowing for faster change. So I can save 2 min by taking count down but add 20 min or more in change time. I have worked for companies (CAT) that want there counts down. Changing Models took way to long. They lost the power of Pro/E because they thought about a small thing. Now I can see why because they were making BIG items and even with there low counts it could take 8 hr to open some files.

I also never said that Object Creation System for SL was silly, Really I see it as a good way to do things. The problem is it needs a few more things to make it really useful. I see it as a great start. As some one that started on AutoCAD Ver (not Rel) 1.2 and now I Pro/E I can tell you I know how silly something can be to use. I would say SL is leaps beyond what I started with and I got to say I like it. The problem is What I can do in 10 min in Pro/E will take me 8 hr in SL if I can do it at all. That to me is the problem.

Actually, in 1.6 the video is streamed directly to your client from the non-SL source, so there is no overhead for the sim servers to support it. Streaming MP3 works the same way right now.

Audio clips streamed from the server are way compressed, and limited to 10 seconds or something like that, and I assume they are well cached on the client side. Textures are also extremely compressed, and well cached.

With the prim system in SL, you can stream the definition of a prim in probably one or two dozen bytes. A vehicle, with say 25 prims, is most likely going to be under half a KB.

The whole concept of prims in SL is brilliant, and you can build fantastic models once you get your head around the concept. You basically have to model using constructive solid geometry, with limited differencing tools.

- Jon

forgive me if it seems apples and oranges, and i missed something pointed out in the above posts....

i use both Pro/E and Maya. and now prims. Pro/E native files act more like prims it seems to me (i'm still a noob). they're parametric. easy to modify shape through construction history. alot like Pro/E. Maya is nothing like that in whatever format - NURBs or polygons (and that includes the messy .iges output you get too).

stream iges? fine, but upload your iges file? LL host all that data? files can be huge. assuming LL did host them, who is to say the surfaces wouldn't tear on an animated object. imagine all these great models with rips in the them as they moved. that's not good; be worse imo. of course it depends on what package exports the file - Pro/E files are tight; but Maya files leak (ever looked at a poorly exported iges in Pro/E to make it "solid"? from Alias/Rhino/Maya/etc). would LL only accept Pro-exported iges? different quality outputs from different apps invites problems.

stream NURBs? maybe. but have you tried building a Hollywood style NURBs model using patch model techniques. nightmarish and time-consuming. and even those rip which is why so many CG people wonder why anyone bothers with them.

stream subD? maybe. better than straight polygons which is how the current mesh appears to be constructed for the AV's. not sure. it's really caught on in the CG community. it might fly. but then you might have different standards again just like with iges.

stream parametric? Pro/E already has Groove built into it to basically do just this for long-distance collaboration (have seen it, but not used it - and btw, Microsoft just bought Groove). now if you went to a Pro/E style format then you'd have small files and parametric abilities. great for us with our own licenses, but not very considerate of those unable to drop $4000 for a seat. and then what about the SolidWorks people? or the CATIA people?

i can understand LL decision. i've started getting involved in the open-source RepRap project, and one facet of that is the inclusion of a free CAD modeling app. seems like LL should watch this as it may be a unique opportunity....

Thank you for your input all. It helped me at least understand why, even if I disagree. There are work around for all the problems that have been listed BUT it really does not mater SL does not have the capability and no reason to go on. Thank you all for your input.

Must I chime in?

I think, ultimately, that we'll see 3D model imports of some form, even if they end up being NURBs. It's pretty much inevitable, and the Lindens want to do it last I heard... it's just, well... technology is getting there. As internet speeds and new advancements continue to build, I think we'll get there.

I also think that the Lindens will ultimately cap resident object usage, especially on stuff like 3D models. This is also a technical restriction that is inevitable unless storage tech advances faster than people can use it, which it may well be. Already Google's Gmail hosts a free Gigabyte (!) of storage for all users, and I frankly don't want to think about what lump size my inventory is in some DB at the other end of the US.

At any rate, if you can convert the file to OBJ, use this. It's not a feature, but hell if it's not useful.

agree. Pro/E has managed to incorporate CDRS (aka "Pro/Designer" directly into their system (even though i prefer Maya/Studio for freeform objects). and there were two developments i blogged about on the memory side - Philips and IBM both had breakthru announcements at CeBIT.

personally, i'd like to see the parametric side. i enjoy using Maya (have a seat) and Studio (while corporate), but i really enjoy Pro/E (even if their support sucks, imo). and the options for a good parametric are personally very intriguing...

Support? Pro/E has Support? Man all I get is people that know nothing about the product and just tell me to Export my Stuff out of Intralink (PTC’s [maker of Pro/E] PDM [Part Data Management system]) and then import it all back in. All it does is mess things up more. Oh well. One day one day. I think that Importing things in are coming. I would think STEP or IGES files is the way to go. File size restrictions I can see. Each person has only X amount on there property and unlimited in your inventory seeing that can be saved on your hard drive.

Full IGES support would be terrible overkill if only because there's so much software out there that produces broken IGES files--I use Rhino for industrial design and rapid prototyping, and its bulletproof IGES importer saves my pretty posterior every time I have to import an IGES file from Pro/E or Solidworks.

But that aside...

There's probably a middle ground between importing IGES files and the current set of prims. After all, all prims get rendered into triangles anyway, and trees show that the engine isn't limited to simple solids. Even something simple, like a closed polygon mesh with texture coordinates and an upper bound on complexity to keep its rendering load in line with the current prims, would really expand the palette. The SL client can already handle complex meshes (avatars) and multiple levels of detail (trees)...

--Arashiko

I understood maybe 1/10th of what has been said but I still found this thread a interesting read, thanx guys

"The SL client can already handle complex meshes (avatars) and multiple levels of detail (trees)... "

but apparently only one mesh using what amounts to blend shape modification (or whatever they're calling it, i guess). having looked at the base file, i now understand the steroidal pecs on my bod ("I was a juicer". and a parametric model can be translated to various levels of triangle detail; do it all the time going from Pro .prt to an .stl file ( or .obj or whatever) - i suspect LL has a nice LOD set up with their parametric prims. can do that with polys i suppose, but i don't know how much automatic poly LOD generation has improved in the last 5 or so years... Q3 models required the modeler to make them and include each LOD version in the pk3 file (so three models per Model and all the associated UV detailing aso). i've read of advances, but don't know the details. even so, i'd guess parametric files still have the edge in LOD generation.

as for Rhino, i'm sure it imports CAD iges just fine, but i've received my share of crappy Rhino iges exports for import into CAD. don't get me wrong, Rhino is great, and the file translation is very good. but even it has issues in this area. after all, i can import a Pro/E into Maya w/out problems also. it's going into CAD that's usually the issue. tolerances mostly.

oh well. not like anything we write here is going to change things. just means i have to spend more time on textures