herbieherb

I use classes successfully for multiple states, variants, levels of detail and for before/after rebuilds. I just put the whole thing into a group and the group gets the state class etc. Why do you have to pack these features into separate tools when the classes already solve all this? The classes can do so much more than just assign attributes.

Can we add 2D-objects into the autohybrid-object to make annotations and similar?

Fortunately Vectorworks stopped you. The image of your park would have had an uncompressed file size of more than 1000 terabytes. Use the size you want it to be printed in the end. Choose the quality by the dpi. Usually bigger images need less dpi as you look at them from a certain distance.

The export is correct, when you zoom in, the lines are shown correctly. They are only shown in gray on the screen by the PDF viewer when you zoom out. If you print the PDF, they are also correct.

When you work on big 3d models, you really notice every 10% increase in performance in OpenGL mode. The model loads faster, you can navigate more fluently and changes in class visibility etc. are faster. In Vectorworks its a good idea to also max the OpenGL score. It doesn't seem to be only a bottleneck when filling the gpu, because the navigation in an already loaded model is also smoother on the other system with the higher OpenGL score.

Again: They testet the SC speed not OpenGL. You're right it doesn't matter much for renderworks but for OpenGL the right RAM configuration makes a huge difference up to 30% between a 2133MHz (most ECC-Modules don't go much faster than cheap normal RAM) and a 3600MHz (very High-End but non ECC RAM) configuration. I tested it myself with different RAM modules. So if you want to exhaust a high-end gpu, you have to use very fast ram with the treadripper. If you want to buy the cheaper ram you coul'd then also buy the cheaper gpu since it would'nt matter. Example: I got a machine in the office with an i7-6700K (4cores at 4GHz) RAM at 2133 MHz and a Geforce GTX 1070. It has an OpenGL score of 140 frames. The threadripper built i introduced even though he had a GTX 1080Ti with 2x2133MHz RAM only had a score of 100 with 4x2133MHz RAM it had 105 with 4x3200MHz 116 and another user at this board had with 4x3600MHz 134 frames So between the 4x2133 MHz and the 4x3600MHz there is about 30% speed difference in the OpenGL Mode (in SC, MC Tests the difference is only about the 5% as you mentioned). So when you render, you wont notice a difference. When you work in OpenGL mode with huge 3D Models, when you use multiview or use high screen resolutions (several 2k screens or a 4k screen) this definitely makes a huge difference.

Please read the posts above again @zoomer. Your video is not relevant for a threadripper built for vectorworks: Also it seems that vectorworks doesn't use ecc at all: If you really want to use ECC RAM. Get one of the new Xeon not a Threadripper. But you'll get less power for the money. @iaincognito I woul'd definitely wait for the 2950x. Don't try the Noctua cooler. I tried it myself and the threadripper got really hot. Get a water cooler. Make sure that your case is capable to fit the water cooler. If your water cooler has three fans your case must have room for three coolers next to each other. Get a case with good case cooling (same amount of fans as the water cooler). So if you get the water cooler with three fans your case has to have at least 6 positions for the case-fans, three of them next to each other. Make sure you'll get the G.Skill Trident Z with the indication RGB F4-3200C14Q-32GTZRX. These are optimised for the threadripper. Also consider buying even 3600Mhz RAM as another user did. His cinebench openGL test was 15% faster then mine with almost the same system. But this did only affect OpenGL. For the monitor i prefer more than one but smaller size and only 2k not 4k. With three 2k screens your gpu has to handle less pixels than with one 4k but you'll have way bigger screen size. Also the vectorworks pallets can thus be better distributed. But I guess that's a matter of taste.

1. ECC vs non-ECC When you assemble a threadripper, you prefer higher RAM clock rates. The threadrippers like fast RAM with low latencies. Take the fastest RAM you can afford. Don't believe this video when you want to use ur RAM in a threadripper built: https://www.youtube.com/watch?v=D_Yt4vSZKKVk He didn't test the threadripper and he didn't test the OpenGL speed, the interaction between processor and graphics card. Here you are 15% faster than between 2133 and 3200 MHz. Between 3200MHz and 3600MHz there is another 15% speed boost. ECC doesn't give you such fast RAM. So you would have to give up up to 30% performance. Maybe if you want to use ECC RAM one of the coming out fast clocked Xeon processors would be better. But you'll pay a lot more for that system. As I said before: The probability that you will ever crash while rendering due to a memory error is in most cases negligible. ECC could only be worthwhile if your computer is to render reliably overnight on a regular basis without being monitored. 2nd Ryzen MC renderworks boost vs Intel's higher SC bench speeds That would have to mean more expensive but better render computer vs low-cost general-purpose machine. In everyday drawing with Vectorworks, the lower clock rate of the threadripper 1950 is hardly noticeable. The 2950 is even faster. The difference is really small and in the future more and more processes will be multicore capable. So it's more a matter of budget than the choice between single and multicore performance.

Woul'd be great if it does. I already missed the accessibility of the tags we can set in the VW2018 resource-browser. No chance to get this attribute in a worksheet. I also definitely want to use these tags in the select similar tool.

Yes, I would definetely also recommend the threadripper 2950x. But it's gonna cost you much more. You would need water cooling, the mainboard would be more expensive and to tickle the last one out of the processor you would need faster RAM. That means to you: Mainboard +200$ Watercooling +100$ Processor +500$ RAM +500$ Total +1,300$ So if you have a fixed budget, you'll blow it up. But if you figure out how much less time you have to wait in front of the PC until the rendering is finished, the investment is worthwhile anyway. When you say you're rendering 20% of your time. Then maybe you would be half busy with settings, the other half would be pure render time. So about 10%. That would be about 50 minutes at a normal working day. With the Threadripper 2950x you would be about 3x faster. You woul'd only need about 16 minutes, then. So you save 30 minutes per day, but you have additional costs of $1300. Depending on your hourly rate, you would have saved the additional expenses after less than a month. Here a detailed discussion about the threadripper:

The newly announced Xeon processors are based on the Coffee Lake processors. The 6-core 3.7GHz clock is basically an i7-8700K but supports ECC Ram. When rendering, most RAM errors are negligible and result in a single misrendered pixel or the like. Only the very few really cause the rendering process to crash. With 64GB RAM an error happens 8-20 times per month according to Google study in 24h operation. If you use your PC only during working hours, you will have 2-5 RAM errors per month, most of which will have no consequences. For my purposes, Vectorworks runs absolutely stable without ECC RAM, but some users who render overnight and therefore depend on stable continuous operation rely on ECC. Of course, it's much worse for them when the work of an entire night is gone the next day. I understand that they use ECC. For normal rendering tasks, however, it is only a nice to have on which you will never really be dependent. So I wouldn't wait until the new Xeon is on the market, but buy the i7-8700K you planned.

Are the tags accessible in tables and scripts? We have a simlilar tag system in the ressource browser that isn't. Could they be made accessible via commands similar to those used to read the databases?

Here is my SymbolToGroup node. Not fully tested but works at the first glimpse. SymbolToGroup.vwx Edit: I tested the node in different situations. The old one put the output into a second group and did not work with multiple inputs. So I edited the node a little. This one should work like you are used to from other nodes.

There is a vectorscript function for this: SymbolToGroup. Unfortunately I can't find a way to output the handle of the created group from the node.

Thx for your effort. I want to convert an already inserted symbol to a group. Similar to the ungroup node but for symbols.

I can't find a node that converts a symbol to group. Has it been forgotten or is there another way to do it?

Here is my battlestation: The screen layout: I recently added the third screen for the 2018s new multi view feature and it has really proved itself. I also sometimes use the left screen for other software like excel tables, pdfs and stuff. Here you see the engine thats hiding under my table: You can find more information about the hardware specs of this custom built in this thread:

Of course we still have problems with project sharing from time to time. But most of them have to do with the users themselves. For example, if someone moves the project file, or gets a new work file after a crash without releasing its checked out objects, or one confuses a very long lasting release with a crash and the like. That sharing can take an eternity is really still a problem. This is usually the case if many layout levels have been processed. We have gotten used to releasing layout layers more often when editing between them.

If you work on PC, don't worry, projectsharing is absolutely stable. On Mac there were problems because macOS is struggling with network protocols. However, Vectorworks was largely able to circumvent this. I would never be discouraged from at least trying out new functions because of such messages. You only learn through trial and error. If your team is already able to work with references, project sharing should not be a problem for you, because it is much easier and much more efficient to work in a team than with the reference method. I would also consider buying in know-how with a new employee. At least one member of the team must be an expert in the CAD used, otherwise drawing will never become efficient.

Does this mean that Windows users will also benefit from this Apple decision? Will the Windows version of Vectorworks switch to Vulkan at the same time? Will Vulkan mode benefit from multi-core processors because of its basic multi-threading capability?

Here is a way to change the symbols' origin without to move them on the drawing: Go into the edit mode of the symbol. With the containing objects you create a new symbol within the old one. Choose the origin as where you want it to be. Move the rest of the 2D, 3D and wall opening contents into the new symbol. Make sure they are they keep its relative position, as the origin is now at a different position. Leave the symbols edit mode. With "activate similar" you now activate all your instances of the old symbol. Convert the symbol to groups and ungroup them all. Delete the old symbol out of your library and rename the new symbol using the old name.

This really looks like an origin issue. Just pushing the origin onto the drawing does not help. This does move the user origin but not the vectorworks-origin. In the menu go to origins (Extras-Nullpunkte-Benuterznullpunkt festlegen) and delete all user origins. Then you move the entire drawing to the vectorworks origin.

It is not the way Vectorworks works to offer a single correct method. This may be considered a weakness, but many here find it exactly the strength of Vectorworks. It is an open package and can therefore react flexibly to new requirements. If you really want to have different versions in one plan, then this is possible. In many different ways. Isn't that great? Of course it makes it very complicated. It takes a lot of experience to apply efficient drawing strategies. An external draughtsman must first be introduced into each project. This is the price for great flexibility and freedom. A simple versioning system would not correspond to the Vectorworks philosophy. Rather, it would be great if we could assign several classes to objects. One for display, the other for additional visibility options. This would simplify versioning, because you no longer have to group. I even have in mind a fusion of classes and database. Each object would then have one class for display and any number of other attributes for further classifications. All current database entries would then come in here. The object attributes, general visibility and versioning, data visualization, BIM data and other databases would be integrated into a single system. That would be the real Vectorworks way. Translated with www.DeepL.com/Translator

Even without OC I would install a water cooling system. Especially when it comes to the longevity of the processor. Lower everyday temperatures mean longer service life. There are very inexpensive all-in-one water coolers which are very easy to install, e.g. the Fractal Design Celsiuses. When you use the Threadrippers, and you have the choice between two and four ram bars, always take four. Since the Threadripper supports Quad-Channel ram, with only two bars you give away half the bandwidth. 2x16GB or 4x8GB both cost about the same. However, the 8GB bars are available with faster clocking and lower latencies. The Threadripper processors benefit from this to an above-average extent.

Turn off indirect lightning and HDRI Lightning. Then modulate the shadow darkness by the ambient lightning.