Petri

Yes, it would be nicer to query the font file... Alternatively, the users formats the output once, then the tabbing is stored in a text file. (I'd of course prefer to store it in the parameter record, but I can't get writing to thenm to work.)

I assume I can use DOMENUTEXTBYNAME to convert an M to polylines, then if needed even to a group of lines. There I would have the height, ie Em.

Orso, I'm investigating the Em-measurement & average width of characters in "normal" typefaces. Unfortunately, the people I know who are currently in typography do not seem to know whan an Em is... The concept is this: - measure Em of the user's font in current scale - calculate the max number of characters in source data - calculate the required tab spacing using the average width in Ems - set the object variable to be as needed

But no GeoTIFFs? Is there any documentation regarding long/lat? I might want to write an import & export translator for MapInfo files. I already have one using flat earth projections, but it is a hassle for the other parties.

I don't think so. You need to create gradients (2D work) or textures (3D work) for full 24-bit colour. You can switch, but all colours are interpreted to the current palette.

I noticed that there is an object variable called "georeferenced" (or thereabouts). Does this mean that we can import GeoTIFFs to their defined locations? Another interesting thing was "long/lat" -variable. This of course is needed in GeoTIFFs, but can we also import vector data in long/lat -coordinates?

Can the service plot from DXF? If not, then maybe the solution is CADintosh or GraphicConverter. The former can read a DXF-file and write an HP-GL -file, the latter reads PDF (vector) and writes HP-GL. Hmm. I guess I did not read carefully... Only an ancient Mac? Pen plotter? Dumping a plot file from a Mac to the plotter is possible, but not, I recall, easy.

Createur, I know what you mean... Batch export would be great - but I don't think really doable. Even the PDF batch export handles only the current file. You don't give enough information for proposing a workaround, so I'll just make a lot of assumptions. You might test the following with the engineers: All floor levels of each building are exported as a single file, with each floor a separate layer. Export data limited to only what they really need; pen colours not ByLayer. When the engineer XREFs the file, he or she can turn off the non-relevant layers (floors). In your end, you would use Workgroup Referencing to automatically assemble the document used for the export. (If this sounds complicated, I'm more than happy to come to Copenhagen for a few days to show how it is done for a modest fee - like expenses and free beer...)

Orso, the units are drawing units. In a "table" I set the tab to be 5500 mm!

I hope so, Erich. My apologies for feeding a troll.

I was just about to try with an alias... Why can't this be in Preferences? Or even as a config file - locations for this and that.

Thanks, Orso. Seems to work with either. The value is in world dimensions, so there's an interesting exercise in determining how much space one needs. Converting an M to a polyline and measuring that, then making assumptions on the character measurements (in Ems) of some likely fonts? Nah, I'll hard-code Courier and let the users worry.

I would probably create a floor of all beams in question & of same height - a single floor, that is. Another of larger beams, perhaps (primary/secondary). So, draw the rectangles first, select them, say "Floor". Second question: no automation for this (AFAK).

You can add (and remove) sizes by editing the relevant text files in VectorWorks Folder:Plug-Ins:Common:Data Eg: RectangularTubing-Metric.txt Tee-Metric.txt SquareTubing-Metric.txt RoundTubing-Metric.txt WFlange-Metric.txt Channel-Metric.txt IBeam-Metric.txt Angle-Metric.txt BTW, I find the 'a different object to each different section' -approach counterproductive, so a few years back I created an universal steel section object which allows one to change an already-positioned section type with something completely different, eg. an I with an RHS.

It seems we can't set tabs with VS. This would be quite useful, at least in my opinion.

You don't obviously know anything about this aspect, either. The client owns the data. Everything you have written is totally irrelevant, has nothing to do with Product Modeling or comparative capabilities of different CAD-programs, so it might be good for your reputation (if any) if you'd embarrass yourself in something else for a change. You have so far managed to demonstrate a deep and profound ignorance on anything related to Product Modeling, collaboration, ownership of data, large clients and projects - but whatever, go on. I'm sure there are other areas you know nothing of. No, you know little and little knowledge is indeed a dangerous thing.

DOMENUTEXTBYNAME should work.

I've been thinking this matter a bit, from quantity/costing point of view; considering how relevant data could be extracted with scripts. While with wall styles it is possible to interrogate the style and find out the fill style (eg hatch) of each component, I think it would be more straightforward to have classes for the purpose. So, my final (for the time being) wish is that floor and roof styles will use classes in component definition - and that wall styles are further developed in the same way. There is certain merit in the current approach in wall styles (an additional data structure), but on the balance I believe classes would be both sufficient and better. (I think most people hate hatches, especially creating and editing them. True, a name only is enough, but nevertheless.) The purpose of the script(s) is to generate raw data for processing in a relational database - which we are obviously not going to see inside VW, if my reading of some recent messages is correct.

Look, you obviously don't know the first thing about the subject so why don't you go and put some lattice to your current carport extension project.

Only in places like Australia. You don't get it, do you? While most product models will be 3D (in fact, 4D), to make things easier for everyone, theoretically the 3D component does not need to be graphically interpreted. Nonsense. Stick to carport expensions. Why do I think that I know much more about data structures, databases, mathematical & logical modeling, dynamic & cybernetic systems etc than you will ever know? The whole point of object-based systems is to enable data to be used in different ways. Yes. The real data is, at present, best modeled, exchanged, interpreted and collaborated with by IFC. Well, you definitely seem to reach well beyond what you know... Maybe. But in architectural design in developed countries it is reaching its use-by -date.

Chris, What you don't seem to understand is that Product Modeling is what the big clients and construction companies want and demand, for their own benefit. Your Aussie mobile-and-4WD-and-a-few-mates "builders" doing carport extensions are something completely different.

For most people Photoshop Elements is quite enough and not overly expensive. I love GraphicConverter and use it a lot, but in retouching Photoshop is far superior. I also bring most renderings to Photoshop for various operations. The most common is quite mundane: after exporting an image file with marquee, I crop and resize it. I may also add a background - usually colour or gradient. Colour balance is another common thing to fix. With layers one can also do some interesting tricks, like add pseudo-shadows to 2D-trees. One export without trees, another with only trees, then merge the files as separate layers and give the tree layer a shadow. EDIT The main difference between Elements and "full" is, I believe, that the former does not support CMYK-colour space. Plug-ins mostly require the full version.

IFC works approximately like this: All CAD-programs (and others, too) use objects based on IF-classes and therefore can see & (if applicable) manipulate them. All files are in the same format. If a program cannot manipulate an object, it is still kept intact in the user's file and when file is transferred to another program, it can be manipulated. (Every object has certain universal properties, but some aspects may be "black boxes" to some programs.) Different programs may have different abilities to manipulate, interrogate etc same objects, in effect, "see" the Product Model differently. Khemlani's points are (as I recall, did not re-read the article) largely based on the practices and industry conditions of underdeveloped countries such as the USA and not applicable to the developed world.

Chris, In some countries ArchiCAD is very widely used. Collaboration is not a problem; in fact, since ArchiCAD supports the object-based IFC-concept (Industry Foundation Classes), which NNA obviously has hardly heard of, the collaboration is much more efficient than between VW and AutoCAD. Then in some countries clients are starting to require full Product Modeling via IFC and in these countries VW will be wiped out in architecture. This is the real world.

Decided to revisit the Actual Ceiling Grid Tool. Unsatisfactory: 1. As comes to workflow, pretty useless. One has to specifically draw the ceiling grid, which almost always means retracing. With the "floor approach", you can very often use existing polygons. 2. Defining the possible angle has to be done numerically, while with bucket hatching you can use existing geometry to define the angle. 3. There is no 3D grid whatsoever. 4. Only one line width for the perimeter & grid. I like to show the perimeter with a thicker line than the grid. 5. No height tagging. No optional diagonal line with text & suppression of the actual grid. In, say, permit drawings we do not want to show any grids, but need to show the room heights. Good points, too: 1. Can be converted to a group, then extruded in two parts, belonging to different classes. Only slightly more cumbersome than my old practice. 2. Allows experimentation.