Thats because you have all the components in the Revit Native as nested families, which adds each nested family to the file size

The Inventor import is simply a block, not parametric, your Native Revit one has parameters to flex the connector and the pipe flange, this isnt possible with the Inventor import

Although you wouldnt use the 3D model in documention views except for 3D, the elevation and plan views for the inventor import look average compared to the Revit Native

It would be intresting to setup a test project with a few hundred instances of the family and run some benchmark tests, this is the reason most will never use this type of imported family, as the risk of it affecting your projects performance with hundreds of instances is not worth it. I tried to set something up quickly, but the families are not consistently setup for their hosts meaning I couldnt just switch the families

1. The file from Inventor has a bunch of additional parameters in it that get grouped under "Model Properties," that then get tossed in to the project, and dont correlate to any parameters for any regular Revit families. Yuck.

2. I dont see any material controls on either family. The catch is, i know i can put them on the revit geometry. WHat about the inventor one? Im assuming you can, and the people who built these just didnt. But i would want to see that, because its a huge sticking point with junk Imported Content.

3. How does it handle it if you have that exact same faucet, but with 6 different lengths of the main faucet drip?

4. The entire Inventor piece of content is on the subcategory "0". Yuck.

5. Performance. So, this one is hard to quantify. Not because i dont see a difference (i do), but because im not going to run a bunch of journal benchmarks to confirm what i already know. But here is what i did: I placed 100 of them in a blank model. 3D orbited. Panned, selected them all, 3D orbited again. When it was native revit, it flew. Did the exact same thing after placing 100 of the Inventor imports. When it was just he first few, it wasnt a big deal. When i had all 100 placed, and 3D orbited, i didnt see a difference. Panning, no difference. The moment i selected them, and tried to orbit OR pan, the refresh took longer. Noticeably longer.

Thats in a completely blank file, with nothing else in it. But window selecting fixtures happens ALL the time in projects. Not acceptable. Now, to be fair: I dont know if its necessarily the "Inventor-esque" nature of the file, or something else. But to me, it doesnt matter. If its crummy revit, we wont use it, and if its causing performance problems, we wont use it.

As i said, i dont believe having downloadable useable content has any chance of helping you get your product in buildings (i think people pick quality products from the design standpoint, then they go looking for content... at least, thats what we do), but as far as the production aspect goes, items 1-5 above are all reasons we wont use them.

1. Additional parameters = mucking up the available fields/schedules with useless crap. Probably (a guess) also means i cant have any REAL parameters with the same name, per category. Interested to see how that plays out.

2. MAJOR deal breaker. We render. A lot. No render control = no use.

3. No parametrics? Depends on the model, i guess. If it truly is available only in one size, no biggie. But if the intent is 1 model number = 1 size, and youll just litter your website with 2000 families = no use. That clutters up our files with useless family definitions that are basically redundant.

4. This one is just freakin stupid. WHY the subcategory of 0? I mean, i know its a "layer" thing. But thats not good enough. WHY is it there? Thats even more lousy because in the family the IMPORT is set to NONE for subcategory. Yuck all over again.

5. Speaks for itself.

Now, if youve read the forums, you obviously have caught on that im pretty strict about my implementation of Revit... But ill tell you something: On Revit forums everywhere, the software has a reputation of being difficult to use, tempermental, not user friendly, and unstable. By your own post, you said some things are "hard to model." I find ALL of the above to be completely based on users not knowing what is and is not good for the tool, in implementation. Ive got insanely complex models here, with all trades included, that hum and perform wonderfully, and we leverage them to the max potential. If some people think its *good enough* to use imported Inventor files? <shrug>

Knock yourselves out. =)

An ADSK file from Inventor is nothing more than a dwg (or series of dwgs) and XML Files in a wrapper. The wrapper is an ADSK file format which is ultimately a zip file. So if you think it's good enough to use dwg, then you would be ok with ADSK.

Just to second Aarons opinions! I´d never use the Invetor Import Family in a real project

And BTW, even though I´m not a big fan of "over modeling" there should be a small gab between the moving parts (It´s in the inventor file, but not the native Revit file).
Without the gab, it´ll render as one solid piece...

And remember to add material parameters (and assign the Geometry to those parameters), as Aaron also pointed out.

Also, this family is easily built without nesting all the different parts, instead I´d recomend to built it as a unhosted family in one piece, which then can be nested into a wallhosted, and or facehosted families.

And... remember to set the proper subcategory for the Geometry (Not "0")

Thanks for your input again guys, I ddn't create these samples a 3rd party did, we just sent them our Solidworks file and they modeled from that. I sent them your recommendations and should have the updated files to post tomorrow.
Aaron:
Hopefully tomorrow all the problems mentioned will be fixed except obviously the Performance, which is the main one i suppose.

I'm 100% for doing this in Revit, its just so so hard to convince anyone in Sales that's its the right way forward (all they hear is triple the price, for the same thing). Its amazing how far behind Australia is 90% of people i have talked to here are open to using this type of product, but as I'm realizing its not because ADSK is viable, its just because there so new to Revit they don't no what there doing. We have had sit down meeting with a 3 or 4 architects now that have said they will use it HAHA! my head hurts! This is ridiculous. Im telling them not to do it with Inventor and they all look at me funny.

It´s NOT the same thing It´s like comparing a old Chevy with a Porsche

BTW, connectors won´t nest, so if you go for the unhosted nested in facehosted as I suggested, the connectors must be applied in both files... :banghead:

Yeh I KNOW there not the same, but its hard to get that across to them. They get a little scared when i mention "some companies WONT use them". Thats about all i got!!

In answer to some of the questions posted about the Revit Native file (created by me). I realise there is no gap as pointed out in the thread. Ideally would have included a gap not only from a rendering perspective but also to identify that they are infact 2 pieces not one.
There are Materials mapped to geometry via a Material type parameter. The material in this case is all stainless steel, except the hot and cold water identifiers.
I could have created the component in one non-hosted family as suggested then nest into a face based family, however I created this component in this manner to enable other models to be created within the tapware series.

It's by no means perfect and would need some tweeking to improve the family overall.

Hi Guy, and welcome to the forum.

The materials in the above family are mapped in the nested geometry, but the parameter is not linked to the parent family.

And if you plan to only provide it as a hosted family, then :thumbsup: for making it facedbased, and NOT wallbased. :beer: