Petri Sakkinen
-
Posts
110 -
Joined
-
Last visited
Never
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by Petri Sakkinen
-
-
Katie - you are a legend!
(I sent the problem file to her and the solution she provided was to draw a nurbs curve. Conversion treats a 3D poly as a closed poly and there were thus indeed very sharp 'end' vertices.
Conclusion: the tool is useful - if you know how to use it.)
-
The 3D poly was created with the 3D poly tool - tracing a bunch of 3D loci.
-
The required path was a 3D poly with six vertices - total length about 10 metres.No close or repeated points, no sharp bends.
The profile was a 50mm circle.
Tried even with a 3D poly with all vertices in the same y coordinates (to make it definitely 'planar.') Tried first converting to a NURBS. Tried a rectangle as the profile.
Nothing worked.
-
For the first time I thought I'd need to extrude along path, to get a handrail tube on top of posts that follow a bezier curve in plan and are all on different z-levels.
Well, I can't figure out what sort of objects I can use for this famous feature - everything I try fails because of invalid objects.
Can someone please explain the limitations of the feature?
-
Just remember: VW ovals are not true ellipses.
-
I am - slowly - working on a 'buffer' PIO (path object) for simllar purposes. If I ever find the time to figure out the idiosyncratic vector functions of VectorScript, it may find its way to VectorDepot's marketplace. Before it does, I need to know whether there is any commercial demand for add-ons - and that will take a year as they only send sales reports & payments once a year. (I have a modest thingy there as a test and no intention to waste my time to do something that does not pay.)
-
VW does not support long/lat coordinates (or 'map projections,' for that matter). Conversion to long/lat to x/y is not exactly easy, since there are dozens of map projection systems (all more or less inaccurate since a spherical surface cannot be accurately represented with a plane.) Your best bet is, unfortunately, to use a GIS program such as MapInfo as 'middleware' and convert long/lat data into the x/y projection your base maps / surveys use.
There may be some hope in the wish list item: many years ago, Diehl Graphsoft had a mapping program called Azimuth (???), so NNA is in possession of the required core technology.
-
So far, northarrow is the only one that fails consistently, but I have a feeling that it happens every now and then.
When I import a different version of a symbol library (folder), I often only get asked 'Do you want to replace' a few times although the library can have 30 or 40 items. With the drawing items, so far all others have come through except northarrow, with others - well, I really can't tell for sure, but it would explain certain oddities in my drawings.
-
I specifically said that it is not a referenced symbol.
In addition, I have tried to put the symdef in the same symbol folder ('Drawing items') in both files, but to no avail.
-
1. No. There is simply an older version of the symbol, with the same name. (Wrong scale.)
2. No error message. The symbol just won't be updated. Nothing gets imported, so there is no 'almost' the same name either.
Now, this is a VERY serious issue. In this case, I can delete the old definition and place new instances (only a few per file), but what if this happens with a symbol with hundreds or thousands of instances. Reliability is a key issue in CAD - and this certainly does not suggest that one could rely on VW.
-
As a amtter of routine, I import/replace sets of symbol definitions. One - NORTHARROW - refuses to be imported from any (scale-specific) library to any document. All other related symbols (TITLEBLOCK, REVISION, SCALEBAR, REFERENCE) come through just fine.
No 'referenced' symbols. Can be reproduced time and time again, in any file.
Ideas?
-
Well, at least on one case, even those polygons that had obeyed my command, became opaque again. Haven't tested it any more, though.
Let's say that this is consistent enough for all the 13 files in a project to misbehave. In another project - at least for the time being - all 8 files are OK.
The only difference is that in the successful files the bitmaps have not been rotated or scaled, in the other one, they all have both rotated and scaled. Could this be this 'something?'
Fortunately this is not a disaster for the final drawings - they are meant to be in 'paint' mode anyway, but 'overlay' and 'invert' would have helped in certain situations. I have a workaround, though.
-
Bea,
Thanks for the reminder! I have a set of scripts for wall quantification and costing that were intended to go into public domain. You should be able get them in a few weeks' time from VectorDepot. I just have to check that they work with VW 9 & have some documentation.
They are based on the use of worksheets.
-
I am experiencing rather frustrating things with layer transfer modes. In some files they work OK, in some others, not at all and finally, in some very strangely: some polygons apply modes, some don't and some start to apply them when they are moved.
The specific situation is polygons over aerial photos.
VW 9.5.1 Mac OS 9.2 Memory allocation 400,000KFile sizes around 15MB
-
I think the problem is simply the non-planar surface you have created.
A 3D poly, to render reliably, should either be in any of x/y/z planes or a triangle. Of course, theoretically you can create a planar 3D polygon in any coordinate system, but doing that with user-entered x/y/z values requires a lot of 3D trigonometry. In reality, only possible by scripting and/or PIOs.
-
To add: it is unsatisfactory that only the original poster is notified. There are many boards where you are notified also for a reply to your reply. You have chosen wrong software, I would say.
-
I take that the deafening silence means 'no.' Ah well...
-
I am still awaiting for the 9.5.1 LandMark/Architect upgrade so need to ask:
Has the DTM slope analysis part been fixed?
-
Ahh - now I know why I had not seen it! That feature is only available when you create a new topic, not when you reply.
So, I'll repeat the previous suggestion: email notification would be extremely helpful. I don't necessarily want to establish a dupliate thread - but I can't spend hours trawling here, either.
Also, the main proposal of dumping this format and setting up a mailing list still stands. (A certain Reverend might give NNA a hand in this respect...)
A mailing list takes only a fraction of the time and effort!
-
TiBook - RAM is even more important than speed. Unfortunately, at present it seems that OpenGL and MacOS 9 don't like each other, so to get any performance out of OS X, you need also the speed. I have 640MB in my 400 MHz Powerbook and that is just enough, not a bit too much.
Also, get an external monitor, keyboard and mouse. You can then use a 'twin head' setup which I find very useful. (Now my main machine is a 'single head' desktop, 19in display at 1600 x 1200, but occasionally it is all palettes...)
File size: sounds fairly large, (20,000 sq ft - that is roughly 1,800 sq m, isn't it?) but many AutoCAD blocks are very large as comes to number of points - and they are all in 3D. There is no simple solution to this, I'm afraid - well, at least I don't know one - but VW seems to handle large files reasonably well nowadays.
-
Tried VW 9.0.1 - no luck. Still getting Error 4.
-
Well, I hope you get the future changes right as comes to a streamlined production line of high-quality raster graphics. I, for one, run VW, ArtLantis, PhotoShop, Word and PageMaker simultaneously to get the job done and high-resolution TIFFs are an absolute necessity. (I need layer transfer modes, so EPS is pretty mcuh useless, as is PDF.) Just once, get expert help from someone who actually does these things in the real world. (Not me!)
-
Right - makes sense in the light of my recent experiences. (Luckily, I have enough RAM to even run two versions simultaneously.) But can we undo these internal changes? I'm not the only one who relies on Print2Pict. Alternatively, 'Export / image file' should be changed to only export the current print page. (Option?)
-
I am having serious problems with the old mainstay of CAD DTP - Print2Pict.
Usually it works, but occasionally it does not, but crashes VW, with error code 4 (divide by zero).
The strange thing is that the problems appeared, I think, in MacOS 9/VW 8.5 combination, then by and large went away with VW 9 - now they are back.
The files & print areas are fairly large (I often need A2 image files at 300dpi).
Unfortunately, M. Raoult has not updated his fabulous piece of software since 1996. Maybe I have an extension conflict or something? Any ideas?
MacOS 9.2.2 VW 9.5.1
worksheet archeology
in General Discussion
Posted
Any spreadsheet is awkward and limited and in the end, useless. Whenever the capabilities of the VW worksheet are not enough, I export the data and process them with FileMaker Pro.
OK: I'm lying: last week, I had to use Excel, because of the idiosyncracies of a project that necessitated a 'combination' worksheet of two data sets from VW AND the need to send the worksheet to a steel fabricator n Excel format.
However, it would be nice to have ODBC-capablity in VW - but it won't be cheap.