Petri Sakkinen

LOADCELL still works in VW 9 so don't panic. By the time it ceases to work (VW 10? VW 11?) you may have new ideas - or perhaps the entire script has become obsolete. Obsolete VS procedures & functions usually have been supported for at least two releases.

Really? Hmm - I have 2750 messages (starting from Feb 1999) in my file and one of its advantages is that I have filtered my own postings so the average usefulness of the messages is higher than that of the complete archive...

Looking at the discussion again, decided to improve my old script a bit to handle grouping objects in single class: the group inherits the class of its elements if they are all in the same class. The first version puts the group always in the current class. Now, nested groups don't behave well in either version - someone might modify this to be recursive, ie. go to groups withing groups within groups. I don't have the time! Make it a menu command - something like SuperGroup. PROCEDURE GroupToCurrentClass2; { ? Petri Sakkinen 2002 } VAR i, n : INTEGER; theClass, currentClass, prevClass : STRING; objClass : ARRAY[1..1000] OF STRING; obHd, gHd : HANDLE; allTheSame : BOOLEAN; PROCEDURE StoreObjectClass;BEGIN i := i+1; currentClass := GETCLASS(obHd); objClass := currentClass; IF NOT(prevClass = currentClass) THEN allTheSame := FALSE; prevClass := currentClass;END; PROCEDURE RestoreObjectClass;BEGIN SETCLASS(gHd, theClass); obHd := FINGROUP(gHd); WHILE obHd <> NIL DO BEGIN i := i+1; SETCLASS(obHd, objClass); obHd := NEXTOBJ(obHd); END;END; BEGIN i := 0; allTheSame := TRUE; theClass := ACTIVECLASS; obHd := FSACTLAYER; prevClass := GETCLASS(obHd); WHILE obHd <> NIL DO BEGIN StoreObjectClass; obHd := NEXTSOBJ(obHd); END; GROUP; i := 0; gHd := LSACTLAYER; IF allTheSame THEN SETCLASS(gHd, currentClass) ELSE RestoreObjectClass; END; RUN(GroupToCurrentClass2);

It is a Mac issue, not a VW issue. However, ArchiCAD has always been able to use round pens on Macs, so there are workarounds. PostScript (or PDF, for that matter) solves it - the trade-off is that transfer modes for layers also go. Windows systems draw with a round pen from VW - pity about the colours... (darker, even more difficult to control.) And, indeed, it is also an old issue.

A user is frustrated because he can't repeat the command in the same way as he can in Microsoft Office (and, for that matter, although he does not know, in PhotoShop.) He has just received 20 nem menu commands, many of those he might want to repeat for different selections - and trying to remember dozens of shortcuts is not easy (and require guitarist's skills - we need more letters on the keyboard so that cmd/shift/option would not be needed!)

This might do the trick: PROCEDURE GroupToCurrentClass; { ? Petri Sakkinen 2002 } VAR i, n : INTEGER; theClass : STRING; objClass : ARRAY[1..1000] OF STRING; obHd, gHd : HANDLE; PROCEDURE StoreObjectClass;BEGIN i := i+1; objClass := GETCLASS(obHd);END; PROCEDURE RestoreObjectClass;BEGIN i := i+1; SETCLASS(obHd, objClass);END; BEGIN i:=0; theClass := ACTIVECLASS; obHd := FSACTLAYER; WHILE obHd <> NIL DO BEGIN StoreObjectClass; obHd := NEXTSOBJ(obHd); END; GROUP; SYSBEEP; i:=0; gHd := LSACTLAYER; SETCLASS(gHd, theClass); obHd := FINGROUP(gHd); WHILE obHd <> NIL DO BEGIN RestoreObjectClass; obHd := NEXTOBJ(obHd); END;END; RUN(GroupToCurrentClass);

On the Mac you can select all the files and say 'Print'. If you have something like OkeyDokey Pro, it can click 'OK' for you. Dunno about Windows, but surely something similar exists. Inside the document you will be able to run a script that calls all (or specifically defined) Saved Sheets, then says Print. Again, you need outside help to click OK. There was recently a discussion about the topic on the VectorScript mailing list. You might check the archives. VWA has a Print Sheets command, which also links to the Issue Manager.

Duh! Maybe a day off would do me good... What is even more embarrassing is that I in fact demoed this morning it to someone who I want to upgrade to 9 - and my victim was able to show me the errors in my ways. Well, made him feel good, I guess.

There does not seem to be inner (roadside) edges of Bezier roads. The top & outer edge are OK. Also, the width of the kerb is always calculated wrong first - my (well, Julian's) default is 200mm, but it is drawn at something like 175mm and I need to change it to 200mm manually for every road isntance (straight, tee, curved, Bezier). (I say kerb, you say curb, let's call the whole thing off.)

I only get loci, no symbols, when using the Seating Layout object. Yes, the symbol is there. I've tried both directly by drawing the path & with the menu command, in new & fresh files & after restarting, but to no avail. These locked scripts are like having a car where you can't open the bonnet...

Christa, If you don't want to spend money on VWA, my 'Simple Space' object is on VectorDepot. You can also modify it as the code is not locked. In addition, if you already / preferably draw polygons, you can vonvert them to Simple Spaces with the scripts that come with the PIO. If you want to stay with polygons, there are scripts aroung for creating area stamps, but they don't update automatically as in ArchiCAD. My script combo sort of semi-automatically do it and I have been thinking of writing a fully automatic area stamp - maybe one of these days...

I have something like 300MB as the 'largest unused block' when running VW only (normal case for tasks like this) so I don't think memory is the problem. Anyway, as I continued my experimentations, I found out that when I link the DTM layer to individual 'model data' layers, Open GL rendering works. Logistically, this is not workable as I have 'model data' in six WGR files and I really need to have a separate 'composite model' which I can use to generate 3D views of the entire study area. In the other case (small file, video projector) I only had about 200MB free memory as I have only (?) 640MB RAM in the PowerBook.

Did a presentation yesterday. The client has a Sony data projector so it was looking good - until I tried to do a walk-through with Open GL rendering (well, what else...) No rendering, though: I only got single, solid colour filling the screen, different colour every time: blue, green, yellow, red. RenderWorks behaved OK, but was of course very slow. Mac PB Ti G4, 400Mhz, 640MB, 400,000K for V 9.5.0

Reduced the overall size of the model (simplified DTM) and now Open GL rendering fails even more seriously: buildings are at incorrect levels (sunken in the ground). The file is now only 6MB, 12,600 objects. In Artlantis, I have a tad over 60,000 objects. The other change was that I exploded the DTM symbol to individual polygons to apply different colours to certain parts. This is getting on my nerves: tomorrow I should run a design workshop, with real-time walk-throughs & fly-bys shown with a data projector.

I have a rather large file (according to Artlantis, 117,000 objects). It renders OK in Artlantis and RW, but with Open GL, parts of if (floors) are rendered incorrectly, with the sides (edges) invisible (transparent) in a very strange way. Does anyone else have similar experiences or is this 'just' a corrupted file? VW 9.5.0 at 400,000KMac OS 9.2.2G4 / 800MHz / 768MBno other programs running and VW says there is over 300,000K free memory

My woes with the DTM continue - and are getting ever worse. Keeping a running log here, just in case someone else has either similar or totally opposite experiences. 1. The large DTM I managed to generate cannot be regenerated (I wanted to reduce the area). 'No DTM' and 'Error (9, 67)' alternate. 2. I put of lot of time and effort in making a simpler DTM for real-time walk-throughs. Filtered 3D polygns, edited all intersecting 3D polys, created a locus-based data set or 6,500 points. From this data set, I can't generate a DTM at all. I have just, however, received a DTM of the latter data set, kindly generated by Robert Anderson, who says he had no problems. VERY strange! I can't expect Robert to do all my DTMs. (Although I guess it is an idea... we are short of staff & computers... maybe he could also lend me a hand with a small library design project... Hmmmm...) 3. Tried to use the original DTM in a compound model via WGR & layer linking, but the terrain came through in half-scale. Converted the DTM symbol to group and got it to work - but clearly, this is unsatisfactory as a long-term solution.

Well, it turns out that it makes quite a difference to use 3D loci, instead of 3D polygon contours. I was able to generate a DTM from 34,000 points, roughly 2 square kilometres of terrain. Unfortunately, in my strange world, this is not yet much. In a couple of weeks time I need to model significantly larger areas. It'll be interesting to see if the new symbol approach helps - theoretically it should make it possible to do the DTM in sections (each with own symbol name, perhaps even each in a separate file), but the question is how to the resulting jigsaw pieces join together. Anyway, the above is a lot more I ever was able to do in VW 8, so I guess the money was well spent. (Both for VW 9 and a faster machine with more RAM. Much more RAM.)

The 'different algorithm' makes sense and reminded me of the fact that when I was attempting to write my own DTM (before there was one), I indeed found two different algorithms from (as I seem to recall) the web site of the University of Christchurch, New Zealand. The academic paper was a bit too much to me, I must say... Anyway, I have for years needed to filter out duplicate 3D loci, with the below script. No sorting, as I don't think it overall improves the speed that much. The logic is that one can actually see where the duplicates are (unless there are many!) and that may help in improving the source data. Maybe this helps someone else. PROCEDURE Duplicates; { ? Petri Sakkinen 1997 - 2002 } VAR h : ARRAY[1..10000] OF HANDLE; obHd : HANDLE; xh1, yh1, xh2, yh2, xo1, yo1, xo2, yo2, z : REAL; i, j, n : INTEGER; PROCEDURE MakeArray;BEGIN obHd:=FSACTLAYER; WHILE obHd<>NIL DO BEGIN h:=obHd; obHd:=NEXTSOBJ(obHd); i:=i+1; END;END; PROCEDURE CheckDups;BEGIN obHd:=FSACTLAYER; FOR n:=1 TO i-1 DO BEGIN MESSAGE(n); GETLOCUS3D(h[n], xh1, yh1, z); FOR j:=n+1 TO i DO BEGIN GETLOCUS3D(h[j], xo1, yo1, z); IF((xh1=xo1) & (yh1=yo1)) THEN SETSELECT(h[j]); END; END;END; BEGIN i:=1; MakeArray; DSELECTALL; CheckDups;END; RUN(Duplicates);

" Many of us live and die by irrigation " Yeah, they are called plants... (sorry, sorry)

This bulletin board format is ridiculous! I composed a long reply in the postage stamp sized window, then tried to post it, got some message about 'flood control' and a 'waiting period between posts' - and lost all I had done. After an hour, I still get the same message. Now, it is ten hours since the last attempt. Let's see what happens. (Or maybe I have been moderated?) Anyway, I'll try again, now conveniently in BBEdit... Right, where was I? What you say about 'unusual' may indeed be true when you have someone to do a survey for a particular site, but we mainly work with data from other types of sources. In this case, we have a very large data set, the entire Melbourne CBD, as 3D polygons. The terrain (lots, streets) in triangulated. We are adding a few sites and streets (an extension of the CBD) and have no data to speak of. Using some assumed datum points plus the known level of the river, we continued the same approach. However, we can't 'float' anything on this kind of model, so we need the DTM. Anyway, we get a lot of data in this 'TIN' format - just last week, a fairly large area that was modelled in Studio Max. Some surveyors we have been dealing with also don't release 'proper' 3D data (wanting to do the DTM themselves). So, to us, the unusual is usual and vice versa. Needless to say that AutoCAD has handled all kinds of data sets with grace, including attributed 2D contours (typical GIS system data type). Can't remember what the add-on is as we don't have it but get a friend doing the DTMs for us, but I believe it costs something like USD 200. The resulting TINs are of course of little use - no floating, no proposed terrain etc. - but they are better than no DTM at all.

You don't address too many issues in you reply, Robert. I agree that the number of polygons is indeed not a good indication, but in this case, I had 595 vertices. The problem with 3D loci is that sometimes (eg in this case), there would be duplicate loci when two 3D polygon edges coincide. Yes, I have a script to filter out duplicates, but (i) not everyone has is and (ii) it is another step (unless incoporated in the conversion script - not a huge task, in fact.) I've done this conversion many times over the years, so I know what I'm talking about! Creating a subset is often counter-productive: I may need several DTMs in a single project from one large data set (somewhat difficult especially with the current symbol-based approach) or may need to redefine the area of interest. The boundary is an excellent mechanism for these, if only it worked. Speaking of scripts, I wrote my own crude and awfully labour-intensive 'DTM' system in 1994-95. One tiny component is this: PROCEDURE CountVertices; { ? Petri Sakkinen 1995 } VAR t : LONGINT; h : HANDLE; BEGIN h:=FSACTLAYER; t:=0; WHILE h<>NIL DO BEGIN t:=t+GETVERTNUM(h); h:=NEXTSOBJ(h); END; MESSAGE(t);END; RUN(CountVertices); May be helpful for others struggling with DTMs. Finally, the new DTM looks quite ambitious and useful and I hope it is improved soon to fulfill the promises! To me, these are early days with the new version (upgraded to VW 9 only two weeks ago.)

Well, this gets interesting. Since our last exitict episode, I found out that without a boundary, the 57 polygon DTM was indeed able to be generated. However, more often than not, I would need to generate a DTM of a subset of the 3D data (as some of my data sets are several square kilometres and I only wand a few hectares.) So, where are we in this respect?

(I thought I alredy posted this a couple of hours ago, but I can't see it so I'll do it again. Sorry if this is a double-posting.) To mny great pleasure and relief, VW 9's DTM can 'float' (send to surface) PIOs. Considering that in VW 8, even symbols failed in this respect, this is an excellent addition. I still haven't experimented with path PIOs which are quite a problem as comes to their x/y location, at least when one replaces the existing path with a new one. (See Vector Depot for a sample script for this and share the frustration!)

Have a file. Have a layer with a whopping 57 (fifty-seven) 3D polygons. I say 'Site Model,' get the dialog, answer the questions. Get a message: "This model contains no DTM, so the command was not executed." Hello? I don't have a DTM, so I can't get one? OK, so I copy and paste this MONSTER data set to a new file. I say 'Site Model' and everything looks cool. And still looks cool, after 20 minutes, 30 minutes, 40 minutes. The beach ball is rotating, so obviusly, something is happening. After 50 minutes, I force quit. Experiment repeated, but I only have time to wait for half an hour this time, before htting the keyboard again. Have another file. Said 'Site Model', got a DTM. (Glory be!) Made some modifications. Tried to regenerate model. What VW now says is that 'NNA_Hidden_record is missing' and nothing happens. Copy and paste to a new file, and everything works again. Hello? How did this cursed hidden record go AWOL? This is ridiculous! Mind you, with AutoCAD and a very low-cost DTM generator, I have quickly and without sweat generated DTMs with thousands, even tens of thousands, of 3D points. VW 9.5 MacOS 9.2.2 G4 800MHz/768MB, 400,000 K allocated for VW

The pad tool sounds good, but the prerequisite for any usefulness of it would be the ability to determine the parameters for the proposed terrain, ie. desired/maximum/minimum grades around the pad. The 'control fence' should also be an independent polygon, with the ability do define where the contour 'control lines' are, ie. where the ridges and valleys go. (Our new land forms are often geometric.) Now it generates practically useless results.