P Retondo
-
Posts
1,914 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Articles
Marionette
Store
Posts posted by P Retondo
-
-
Any clues? VW 9.5.2 crashes when printing to my HP DeskJet 1220C. Printing to an HP 4V and to the HP 650 plotter causes no problem. Printing using VW 8.5.2 to the 1220C no problem.
This printer is networked using a JetDirect box. Just installed the latest driver for the 1220C printer, no help. All the appropriate printer selection and settings windows appear, but when the program starts to output a plot file, it crashes immediately. Disappears from the screen. Nothing but desktop.
WinXPP4 2.2G, 512 MB RAM
-
Cloud,
You only have to make it once. You can import from one file to another using the resource palette.
-
Just upgraded my 64MB GeForce2MX card to a 128MB GeForce 4 Ti. Significant improvement in realtime walkthrough tool. A model that was displaying very jerky and unresponsive movement is now acceptably smooth. (This is using VW 8.5 - VW 9.5 walkthrough tool is broken!)
I recommend the rest of my system specs: WinXP, P4 2.2G (Dell 8200), 512 MB RAM (more is better!). This was a reasonably-priced machine. It was cheaper to buy the best deal on a Ge4 instead of paying Dell's upgrade price.
Beware comparing an ACAD 3D model to its performance in VW. If you import ACAD 3D objects, they come into VW as a mesh or set of 3D polygons, resulting in very slow processing. Native 3D objects in VW are much faster.
[ 09-04-2002: Message edited by: P Retondo ]
-
Just to add my 2 cents worth on converting 3D to lines and the profusion of vertices that results: one of the big reasons to do this is to be able to delete those and other unecessary lines. Another is to adjust line weights, add conventional drafting detailing, and a host of other reasons important to architects - including adding lines at intersecting surfaces which the rendering engine omits. What we would like is an accessible preference setting which does what your VS routine does, not only for the display of rendered objects, but also for conversion to lines. This preference might ideally be set globally with the option to overide on an object-by-object basis.
-
Matthew,
Just to add my 2 cents worth on converting 3D to lines and the profusion of vertices that results: one of the big reasons to do this is to be able to delete those and other unecessary lines. Another is to adjust line weights, add conventional drafting detailing, and a host of other reasons important to architects - including adding lines at intersecting surfaces which the rendering engine omits. What we would like is an accessible preference setting which does what your VS routine does, not only for the display of rendered objects, but also for conversion to lines. This preference might ideally be set globally with the option to overide on an object-by-object basis. I'll copy this to the wish list session.
-
To put it simply: I want to be able to translate and rotate an extrude (and any other 2D-based solid)using both the 3D space and 2D edit space, interchangeably. So, if I move an extrude 2 inches to the right, or I move the 2D object in its edit space 2 inches to the right, the results are identical IN BOTH SPACES. This functionality should work whether the appropriate working plane is the x,y plane or some other plane.
Try this: draw two rectangles. Extrude rectangle 1. Copy rectangle 2. "Enter" (edit) the extrude, and "paste in place" rectangle 2. Note the relationships. Go back out of editing.
Now move the extrude. Enter (edit) the extrude. Again "paste in place" rectangle 2. Note that the rectangle in the 2D edit space DID NOT MOVE with the extrude.
Now try the same thing with a roof plane and a rectangle. When you move the roof, the polygon in the 2D edit space MOVES WITH THE 3D OBJECT!
This is what we want with all 3D objects. The 2D object you see when editing should move along with the 3D object. We want to move back and forth between the working plane and the extrude edit space.
When the 3D object is rotated with respect to the Z axis, the 2D object should be located so that when you establish a rotated working plane aligned with the new 3D position, the location of the 2D object in edit space aligns with the i,j coordinates of the 3D object.
Sound arcane? The 2D/3D interface is one of VW's best features. It has the power to make modifying 3D objects easy because you can correlate positions so easily in the 2D working plane - but for the one problem illustrated in example 1 above! As a result of the current program behavior, if I want to maintain a relationship between an object's 2D edit space and the rest of the drawing, I have to make all 3D object translations and rotations by entering the edit space and moving the 2D object. I want to be able to simply move the 3D object to accomplish that.
Any questions?
[ 08-20-2002: Message edited by: P Retondo ]
[ 08-20-2002: Message edited by: P Retondo ]
-
Michelle,
You wanted to know if a 1.6G / 512 MB RAM laptop would be a good choice. It depends on how complex your work is, and how much performance you want to have. That is certainly an adequate computer. If you can afford to go up to the 2.0G version, some of the more intensive 3D tasks will go better. The only function I've needed speeds greater than a 1.6G processor for is the rendering of complex 3D models.
-
Cloud,
Are you doing this to create a 3D model? If so, I would extrude a shape to make the wall, then intersect the extrusion with a sphere the size of your dome's interior radius (Model/Intersect Solids).
-
I have given up trying to get "Y" joints to work. I work around the problem using three techniques. 1) sometimes it is possible to "bring forward" one of the three walls (ctrl + f) to cover up a line between walls; 2) you can trim walls to an angle using lines - combine this technique with 1) for some situations; 3) create a mask to cover the joint using a polygon with the same fill color as the wall and make its edges disappear using the polygon edit tool.
Not very elegant, but we've been waiting for 10 years for the elegant solution!
-
Michelle,
I think you will find that most new "Wintel" computers are shipped with WinXP. I've used both XP and 2000, they are basically the same and work very well with VW (I assume you are using VW 8.5 or later). Your performance problem probably had more to do with your respective computers' hardware than with their operating systems. I would recommend getting the fastest processer and largest amount of RAM you can afford if performance is an issue. I also recommend getting a Pentium processor. The Celeron has had some problems with it's backside cache, and I've heard some people report problems with the AMD. I've always stuck with Pentium and have had no problems.
-
Giovanni,
Thanks for confirming that you have had this problem!
Is it possible that the problem has to do with units accuracy? I say that because one thing I did the same day this problem came up was to add layers at 1"=40', when previously all layers had been at 1/4". I also notice that the information palette for the rise and run of roof elements has strange behavior. Instead of showing 3" / 12", some of the corrupted roofs show .003" / .01". When I attempt to edit .003" to .0025", the program reverts the entry to .003". When I change both fields to 3" and 12" respectively, those numbers are accepted. The 6:12 roofs show .005" / .01", which might have been rounded to .01" / .01" if unit accuracy had been downgraded by adding the layer at 1"=40'.
Since VW 9.5 uses 64 bit numbers, this accuracy problem would not be as much of an issue. Can anyone at NNA or among users comment on how likely this explanation is, and are there any tips on how to avoid the problem in 8.5?
-
Added info on corruption: it is possible to restore the failed subtractions merely by "entering" them (ctrl+[) and exiting (ctrl+]). This apparently regenerates the geometry.
On the roof problems, some of the roofs were corrupted, some were not. Roofs were corrupted differently depending on certain circumstances. 6:12 roofs became 12:12. Roofs that had been ungrouped to edit their planes were changed variously. Some 3:12 ungrouped roofs became flat; some that had been gathered into groups changed from .0025" rise per .01" run to .03" rise per .1" run.
Any information on these baffling corruptions would be greatly appreciated.
[ 08-14-2002: Message edited by: P Retondo ]
-
Working with VW 8.5.2 and a 3D model of a building. This morning my file opened up with multiple corrupted objects. All 6:12 roofs are 12:12, all 3:12 roofs are flat, and most but not all solid subtractions are failed.
System: WinXP, P4 2.2G, 512MB RAM
I can fix these objects, but if this is a continuing problem, VW is dead for me and for this office because we are using the program specifically for its ability to create 3D models in a hurry. I have to use ver 8.5 because my new version 9.5 has a bug in the walkthrough tool which freezes the program. Does anyone have experience with these problems? Thanks!
[ 08-14-2002: Message edited by: P Retondo ]
-
Matthew,
Thanks for your further assistance. I am indeed getting the message "A required resource was missing" as the program freezes.
To reproduce the problem: open a new document, extrude a rectangle, set any sun position, set a perspective view, render using OpenGL, start to navigate using the walkthrough tool. After about 30 seconds the speed of motion begins to slow noticeably. After another 30 seconds, multiple redraws of the sun icon begin to appear, then a confused screen appears, and then multiple recurrences of the "A required resource" message, then the appearance of the complete message "A required resourse was missing." At this point, if you wait, you may regain a semblance of normal program function (except that the walkthrough tool will cause a freeze immediately). However, VW then operates slowly and erratically and affects the performance of any other program until VW is shut down. It is not necessary to restart the computer in order for it to function normally.
The full specs on my video card are: 64MB DDR NVIDIA GEForce4 MX 420 (TV out)BIOS version: 4.17.00.45.42Driver .dll's are all 6.13.10.2911
Thanks - any solution to this problem would be appreciated. I could install an old version of VW 8.5 I own, if you think that might work. However, the firm's principal might then want to return the new copy of 9.5.2 for a refund!
-
Matthew,
Thanks for checking in on this. Needless to say, this is both disappointing and embarassing, since the office I'm now working in just bought a copy of VW at my request - they use ACAD for production - and my first whizbang demo of its great 3D capabilities crashed and burned.
However, you did not answer my question. Please believe me when I say that the walkthrough tool on my old configuration was ABSOLUTELY STABLE. Does WinXP have a different OpenGL standard? Does my particular video card handle OpenGL differently? In other words, it appears to me that since VW is not currently forthcoming with a fix to this bug and can't say when it will be available, perhaps your engineers or other users could help me isolate a hardware/OS fix to work around the problem.
-
I just installed VW 9.5.2 on a new computer, and I'm experiencing the walkthrough crash described by chopper4 on May 8 in this discussion area. The new computer has WinXP and a GEForce 4 MX video card. In my previous experience using Win2000 and both a GE2 and GE3 Titanium video card (old system: P4 2.0G, 775MB RAM, 128MB GE3 Titanium), the walkthrough tool worked perfectly. This problem has been described by Matthew G. as a VW bug, which it may be, but 1) has there been any progress resolving this problem, and 2) what is the explanation for the fact that very similar systems either have or don't have the problem? Is this a problem with WinXP, with the GE4 card, with the MX card? Does anyone have feedback on their configurations which could shed light on which component of my current system is involved in this problem?
P4 2.26G512 MB RAM32MB GEForce 4 MX
-
Do the attribute values revert when you select the tool, or right after you use it? If the latter, you probably have an object selected somewhere when you changed the attributes (check your info palette to see). Only if nothing is selected do changes to the attribute palette affect the status of defaults.
Or, it could be a problem I know nothing about . . .
BTW, it helps the tech support folks if you supply your system specs (VW version, OS, processor).
[ 06-17-2002: Message edited by: P Retondo ]
-
In my installation, both 2D and 3D rotate tools work correctly in all views. However, the 3D rotate tool is very slow compared to its operation in VW 8.5.2.
VW 9.5.2Win2000P4 2Ghz785 MB RAM
-
Thanks, Ion! That's a great method. I've seen the grid angle option on its menu many times, and never stopped to think what it might do besides display the blue lines at an angle.
NNA: Still not a UCS. Things which don't work in the coordinate system created by rotating the grid: the move command, stretching (resize cursor), editing via info palette. These tools still operate with respect to the "page" coordinate system. Also, the only rotated constraints activated by the "shift" key are the two primary directions of the rotated grid. Other constraints, as set in preferences, still operate with respect to the page.
Surely with all the code that has gone into these rotated coordinate capabilities, it can only be a short leap to a fully capable rotated coordinate system.
[ 06-13-2002: Message edited by: P Retondo ]
-
Katie,
Yes, you can draw 2D objects that appear to be aligned with a working plane's coordinates, but . . . if you go back to standard top view, you will see that those objects aren't really rotated with respect to standard coordinates. In fact, the 2D coordinate system seems to be totally unaffected by changes in the 3D working plane alignment. Only if objects are converted to 3D will they remain rotated with respect to standard coordinates when you shift back to standard coordinates.
We want to preserve the 2D-3D interface essentially as it now works, but have the ability to rotate the view and operation of tools for 2D operations.
CipesDesign: I used to use your technique, but now use layer links to do the same thing more painlessly. Do your orthogonal work on one layer, and link that layer (make sure you check the 2D objects box)to the one that contains your site background info. Unlock and rotate/position the layer link. Then any updates you do will be automatically transferred via layer link.
[ 06-12-2002: Message edited by: P Retondo ]
-
You can generate elevations by giving your walls an appropriate Z+/- value, and constructing your roof in 3D. Then, when viewing this 3D model from the side, convert a copy the objects to lines and paste the result into a new layer. There is a ton of clean-up to do (i.e., removing extraneous lines), which others in the past have asked NNA to automate, but it is dimensionally accurate. If some things were automated, this could work like automatic updating. But as it is, if you change something in your plan, you have to go through all or part of the procedure all over again.
Try this: draw a wall with 8' height, insert a window or door, change your view to look at it from the side or front, select it and "convert copy to lines." Move the resulting group of lines to one side to see what you have. The details of how you create the window or door affect how it will look in elevation.
You can stretch parts of a drawing by grouping the objects. Then you can use the stretch cursor on the group. I often use this technique with VW 8.5 to distribute a group of lines equally over a given space. VW 9 has a tool for that function. You can also select the objects and scale en masse.
-
John,
What you suggest is what I in fact do. The problem is that in order to avoid error, the VW user should a copy of ACAD and know how to do a few things with it, to place the xref at the correct location. And with VW 8, I believe there is a potential for difficulty if the xref is updated following a change in the location of the VW file origin.
On VW 8, at least, links can't be exported to a .dwg or .dxf file. Again, I think it would be possible to write a function allowing that if NNA chose to do so.
-
defjef,
ACAD does not have classes, only layers - advantage VW!
There is a box in the export dwg dialog that asks whether to convert classes to dxf layers. If you check that box, the ACAD file will have a set of layers corresponding to your set of classes. If you don't, the ACAD file will have a set of layers corresponding to your layers. There is no way to sort some objects by class and others by layer, its all one way or all the other.
In both cases, unless you request otherwise, only visible objects will be translated. As a rule, I make sure that invisible objects are not exported because you can often get results you didn't expect if you don't go that way. The translations are not ideal, but they're a lot better than they used to be! I find that VW 9 is at lot better at these exports when it comes to issues of line weight, font size, dealing with layers of different scales, etc.
NNA: It would be possible to have the translator assign ACAD layers that combine VW layer and class, so you would end up with a set of layers like 1st_Fl_Plan_None and 2nd_Fl_Plan_None. Some users might find this a good tool.
[ 06-01-2002: Message edited by: P Retondo ]
-
Yes, "y" toggles screen hints on and off.
I use VW 8.5.2 and Win2000 as well. I haven't had your problem, which does sound like an abnormality of some kind.
The snapping pattern you describe (no centers) is consistent with having the "Intersection" constraint option turned on ("Intersection" toggled by "w"), but with "Object" constraint turned off. You will observe the lack of snapping to centers if you have not selected the "Object" constraint option (toggled by "q"). Constraint settings are reset when you reboot vW, so if you have accidently toggled something on or off it is often corrected by quitting and restarting the program.
[ 05-31-2002: Message edited by: P Retondo ]
9.5.2 crashes printing to DeskJet 1220
in General Discussion
Posted
Matthew,
Thanks for your reply. Before I change drivers, could you comment on the fact that VW 8.5.2 prints fine using my system, and that only VW 9.5.2 has a problem?