Ive used Digital Project, but not woth Revit. And- while i heard about the lecture- i am very skeptical that "Revit couldnt handle the storage of large amount of unique windows in the project."

In fact, if they are put in Revit as static 3D solids from DWG translation from DP, guess what: Thats HEAVIER than having many types of parametric windows done natively. IE: They shot themselves in the foot. Im not going to slam on the lecture (not having seen it), but im betting it wouldve performed MUCH better in native revit.

[QUOTE=In fact, if they are put in Revit as static 3D solids from DWG translation from DP, guess what: Thats HEAVIER than having many types of parametric windows done natively. IE: They shot themselves in the foot. Im not going to slam on the lecture (not having seen it), but im betting it wouldve performed MUCH better in native revit.[/QUOTE]

I agree with Aaron. Recently, I was engaged in a project where the facade team used DP and the rest of the documentation was in Revit. At DD/CD stage the team tried to bring DP facade in to Revit using iges/sat/dwg etc..but the file was MUCH HEAVIER. Also, when we tried to export DP exported facade as navisworks file from revit it kept crashinig. I then modelled the similar facade in Revit with exactly same LOD and it was only 20MB and no problem in navisworks export.
I would strongly suggest using Revit native geometry as much as possible.
R

Frankly I find his statement hard to believe. Unless he uses a weird workflow:
Dunno how exact the OP's description is, but the guy was talking about different WINDOWS. Let's say they are comparing 3D CAD imports with all different Revit FAMILIES (not parametric types like Aaron suggested). In that case the 3D CAD imports would probably reduce file size. But there are two pitfalls:

1. Revit's database handling is designed for usage of multiple instances or types from the same family. I'm no real expert on how it all works, but imho Revit pulls the "basic" geometry for different types from one source and applies the parameter values, thus creating different visual representations (the different windows you see). Using separate families for all different window types is just a bad workflow, which indeed doesn't uses the advantage of having a database. And yes, if you want to use the program badly, it will behave badly.
2. More important: again the whining about file size. As advocated numerous times (for instance in Aaron's thread about the gazillion mb sized AC's) file size isn't everything. I would rather work with a 1GB native revit file then a 200MB file riddled with cad imports. I'd bet mine is a whole lot faster...

What I’ve understood from the lecture is that they tried different methods. From separate families for all different window types to multiple instances from one families. The graphs showed that all method increased the file size, while Revit manages clean 3d solid cad geometry surprisingly very efficient. In my experience, 3d solids increased the file size and performance, which makes it a bit contradicting. However, the redundant storage of profiles instead of in a centralized location was one of the problems. If you have to change a profile you need to manually update all the window families. (Could the API solve this?) Using a shared families instead, gave problems when driving dimensions on the parent families in the project.

I’ve never done a project with over a 100 different window types so I have no idea. Never had a reall issue with prefomance issue due to filesize of families. I always make a few master families with multiple types and instances. This makes a huge different when a component changes. However, I do see the need for a system that arrays panels, jambs, etc, in a family editor like the curtain wall tool. In those cases a move to DP seems logical to a certain degree.

In either case, I wouldn’t be surprised to see some of those presentation slides appear in the briefcases of a few Graphisoft salemen. What better way to discredit Revit if parametric families need to be done in DP.

They dont *need to be done* in DP, or obviously many of us who do huge projects wouldnt be able to work in Revit. One group decided it was their best workflow, and (ridiculously) tossed out a bunch of misleading information about it. Ive got a model where just about EVERY SINGLE item is a one off (literally: Every structural beam, every opening, every wall, etc). Its *still* all in Revit, and crazy efficient to work on (8 acres, mind you).

Just because someone did it and thinks they found results, doesnt mean they did.