Jump to content

fsung

Member
  • Content Count

    63
  • Joined

  • Last visited

    Never

Community Reputation

0 Neutral

About fsung

  • Rank
    Apprentice
  1. And therefore, by definition, no longer a ROUNDED rectangle. The regular rectangle tool already handles zero-radius corners just fine. Because you're dividing by Zero.
  2. Sure, and if you give 100 children a loaded gun and tell them not to pull the trigger, someone will do it. At what point should Nemetschek's focus shift from providing functional tools for users who use them for their intended purposes to idiot-proofing them against users who attempt to use them out of spec? I can send you step-by-step instructions on non-standard, non-logical usages of three different tools that, when followed, will crash VW every time, which I discovered while messing around deliberately attempting to crash VW by trying things that no one in his or her right mind would ever attempt to do, like replacing a door symbol in a wall with a tree. Would you consider it a prudent use of time and resources for Nemetschek spend "fix" those completely illogical procedures on the off chance that someone out there may actually attempt perform actions that less than 1/10 of 1% of users will ever even think to attempt? I'm sorry, but as a customer, I would much rather Nemetschek focus its resources on servicing the situations that there is a reasonable probability that > 99.99% of users will encounter in the ordinary course of their workflow than the obscure situations that < .01% of users will ever possibly encounter. You can argue that Nemetschek programmers "should" have been smart enough to anticipate a user would try to create a zero radius corner rounded rectangle with the rounded rectangle tool and taper extrude it, and to write a routine to identify and reject a corner radius of Zero in the Rounded Rectangle OPI or to recognize such a condition as a regular rectangle and automatically switch to the rectangle mode, but the fact is that the crash on taper extruding a Zero corner radius rounded rectangle goes back at least to VW 9.0 in Windows, OS 9, and OS X and has not been raised previously on the tech board illustrates just how rarely anyone has attempted to taper extrude a Zero corner radius rounded rectangle as opposed to taper extruding a regular rectangle. Yes, it would be nice if that were the case, but given the myriad of ways it is possible, either accidentally or intentionally, to end up with a condition in which one divides by zero, it is unrealistic to expect Nemetschek to identify every possible such circumstance and still release upgrades and updates in a timely manner. I don't expect ANY software company to have identified ALL the possible error conditions that could possibly arise with their product before it's released for use in the real world. The only thing that matters to me is how the software company responds AFTER a problem arising from an unforseen circumstance has been identified. On that count, Nemetschek, IMO, is better than most companies I've dealt with. I would be shocked if this is not addressed in the next update or release of VW.
  3. NEWS FLASH: taper extruding rounded rectangles with Zero cm radius corners crashes VW, too. I'm just baffled by the fact that anyone: a) is attempting to taper extrude a ROUNDED RECTANGLE with a corner radius of zero; b) is surprised that creating an object that requires dividing by zero crashes VW; and c) would fault Nemetschek for not forseeing someone would be dumb enough to try to create a ROUNDED RECTANGLE with a corner radius of Zero and try to taper extrude it. Sorry, but in my book, this one gets filed in the category of "It's impossible to make something idiot-proof, because the universe keeps making better idiots."
  4. I'm running VW 12.5.1 on a 2.0 GHz G5 Dual with the same graphics card and OS X 10.4.7. Two possibilities: VW 12.5 was/is extremely unstable, and in fact, introduced bugs into VW that weren't present in 12.0 and 12.1. (I know, because I discovered three of them, and have confirmation e-mails from Tech Support and QA acknowledging that to be the case.) The 12.5.1 update squashed a lot of the bugs in 12.5.0, so that may resolve the problem. Another possible culprit is QuickTime. If you're running a version earlier than 7.1.3, update that as well. (The current version is 7.1.5.)
  5. Works fine on my setup. Can't really help troubleshoot without more info about your setup. How about providing some details on your setup? What version of VW? What OS? Processor & speed? Graphics card specs and driver version? Quicktime version? Does this happen only in existing files or in new ones, too?
  6. Check the post by islandmon here Also, Julian Carr's add-on, Windoor offers the capability of creating round windows. Highly recommended.
  7. Christiaan, Have you checked that it's not a class visibility issue? If the rest of your titleblock is ok, make sure that the image is in the same class as everything else in your titleblock. Back when I switched to VW, I ran into a problem with the image in my titleblock disappearing seemingly at random, sometimes with the placeholder showing, sometimes without. After a couple weeks of "Where the h*** did it go? It was there this morning/yesterday/two days ago?" and "Why does **** it show up in that document but not in this one?" Turns out, when I created the titleblock, I placed the image in a different class than the other elements, and the class in question was either greyed out or invisible in the "problem" documents. Moving the image to in the same class as the rest of the elements in the titleblock took care of the problem.
  8. Skip the OIP and use the object's Properties pallet instead: right-click (control-clicking for those with one-button mice) on any object with editable properties; select "Properties" in the pop-up menu; enter the desired changes in the Properties pallet and hit "Enter" or click "OK" to exit. Much more efficient because you don't have to scroll from the object to the OIP, and the object's first editable field is already highlighted. You don't even have to select the object before right-clicking: just right-click on it and go. Works for any object with editable properties, i.e., lines, 2/3d polygons, walls, symbols, plugins, viewports, callouts, dimension strings, etc. Also, unlike scripts and add-ons, there's no possibility that the changes in a future version of VW will break the script/add-on's behavior. [Edited for punctuation.]
  9. Hmm ... Barefeats has updated its report on the octo-core Mac Pro, and the results are suggestive (see the results for six simultaneous exports in QT 7.1.5 and the link explaining the results). Might we see the ability to do multiple, simultaneous RW renders in the near future?
  10. Barefeats has posted early results of its octo-core Mac Pro tests. The good news: for pure CPU-intensive tasks (tasks that don't involve much memory or disk access), the octo-core is twice as fast as the quad-core. The bad news: the octo-core provides little to no advantage on memory- or disk-intensive tasks. (There's a good, non-technical overview of the reasons for this here.) I'll be interested in seeing benchmarks for RW performance on octo- vs. quad-core Mac Pros, but given the amounts of data being swapped around, I suspect the difference will be in the 25-33% range rather than the 50-80% range.
  11. Sorry, but I agree with pgym. While it is true that multithreading OpenGL will speed up program responsiveness on Mac Pros, it provides ZERO benefit to those who aren't using Mac Pros. Multithreaded radiosity, OTOH, benefits ANYONE who does radiosity on a dual processor or dual core system, regardless of whether it's Mac or Windows.
  12. Instead of just running Disk Utility periodically, I recommend running a fullblown maintenance and optimization program, such as Onyx (freeware), Maintenance (freeware), Cocktail (shareware), Mac Janitor (shareware), Tiger Cache Cleaner (shareware), TinkerTool System (shareware). In addition to repairing permissions, these programs allow the user to run OS X's daily, weekly, and monthly maintenance scripts (particularly important if you don't leave your computer on 24/7), optimize the System, reset Spotlight's Index, rebuild the LaunchServices database, delete Application, Font and System caches, verify the S.M.A.R.T status of HDs, update Whatis and Locate databases, view logs, and all kinds of other useful tasks that are important to maintaining a stable, healthy system. My maintenance/optimization tool of choice is Onyx from Titanium. (Maintenance, also by Titanium, is Onyx without the UI personalization tweaks.)
  13. Peter, What possible benefist do you see in VW going multithreaded? I don't give a flying fadoo whether or not mainstream apps (office suites, browsers, mail, etc.) are multithreaded. It's not like I'm typing/clicking/designing faster than my computers can accept my input as it is, so I'm not convinced that multithreading VW (as opposed to RW) is going to provide any real benefit UNLESS it's done in a way that allows individual cores to be linked or segregated on demand so a user to work on one file in VW while another file is rendering. (Yes, I realize the technical challenges to doing that could be daunting, and that that really should be a feature of the OS rather than the program, which is why I'm not holding my breath waiting for it.) For me, the only issue of relevance at this point is rendering speed, whether in RW or another rendering app. RW has been multithreaded since at least 11.5. When I do a render in a RW format on my G5 Dual, I get two render lines simultaneously on-screen, and several posters who have Quad-cores report they have four render lines. So unless the Lightwave engine is limited to four concurrent threads or Nemetschek has limited the number of concurrent threads in RW, I expect there will be a significant reduction in rendering times on the octo-core MacPro compared rendering times on quad-cores. If RW can finish rendering a FQRW animated walkthrough in 24-36 hrs on an octo-core that's currently taking 100+ hours on my G5 Dual, that's all the justification I need; if it can cut radiosity rendering times by 50%, that's even more of a bonus.
  14. fsung

    Printing greyscale

    I'm not sure what you're problem is, other than possibly not using Quartz Imaging. I run a dual 2 GHz G5 w/1.5 Gb RAM and the GeForce FX5200, and have no problems printing B&W or grayscale when I use color on-screen or printing B&W only when I use grayscale on screen. It's simply a matter of selecting the appropriate Quartz Imaging filter. Try this: 1. Open up a file with color onscreen 2. Hit <Command-P> 3. Select "ColorSync" in the drop down menu 4. Select "Black and White" in the "Quartz Filter" drop down menu 5. Hit <Preview> or <Print> Repeat for Grayscale, but choose "Gray Tone" in step 4.

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...