csmilo

Thanks for this thoughtful and detailed information. A couple of thoughts and questions. CPU: We may have to specialize our machines a little bit. Maybe move two of the machines over to 8086K's, and move the 3rd to a TR4 based system for our non-VW rendering needs. That being said, with the the way VW is written, are we going to see the 20% gains that the clock speed increase would suggest between Zen and Coffee Lake, or are there significant diminishing returns? GPU: We had not been considering pro GPUs, as they provide no advantages in our other workloads. The trouble we have been having with assessing GPU performance is the availability of Windows based OpenGL benchmarks. I am very familiar with the Linux based benchmarks, as I refer to these frequently when building video playback systems (which use HAP-Q, so GPU performance is relevant), however I do know that AMD's drivers have a disadvantage in certain kernel's which is not reflected in windows. I have seen conflicting information about how well there cards perform in Windows OpenGL tests. Some software tests show Nivida cards handily defeating AMD cards, other show the opposite. What are some specific benchmarking applications, which use OpenGL, and whose results are ranked separately from DX11 tests, whose test regime is similar to the VW workload? Other notes: 1, 2 I think a little more information about our use case is needed. The summary of it is, that because of who generates these PDFs, how they are generated, and what we need to do with them, we need to find the hardware to handle the workload, rather than try to cause other firms to change their processes, or disable the tools we need. There are political complexities that I would rather not get into here related to when and how we get brought into projects. The main way we receive drawings to be annotated is being given pre-formatted PDFs, which do contain vector information, rather than being rasterized, and that we are expected to return for direct attachment to a drawing set, rather than being incorporated into the source drawings and models. This is why we don't often ask for CAD files anymore, as we often can not style these to look exactly like the directly exported PDFs of BIM applications. So ultimately, if the answer is, "you need to buy a phase change cooler and overclock to 5.5ghz", then this is a better option politically and financially for all parties involved. Snapping and doing work on top of giant PDFs is the main thing we do. EDIT: The above largely relates to our architectural work. For our arts work, the PDF's we receive are often the only remaining drawings of a space or site, produced in a long dead version of autocad, whose source files were created by an entity which no longer exists, or who is no longer under contract with the client. 3, 4 Our main use of IFC's is for internal design discussions, and client conceptual flythoughs, and as such these suggestions are greatly appreciated. As noted above, these models are not useful for us as a method to output work product, so we can absolutely afford to lose any contained information. This is also why we are primarily concerned with display fluidity above all else. Again, thanks for the tips. 5 Understood. We don't have many issues with spotlight. I guess we'll re-evaluate our processes when after we perform the hardware upgrade, and after VW2019. Thanks

I work for a small consulting and production firm which works in the field of lighting and video for architecture, and the arts. We have three multipurpose workstations which are coming up due for an upgrade. About half of their time is spent using Vectorworks 2018, and the other half is dominated by Adobe products, and running the Disguise (formerly D3) designer application. There are a several key points where we would like to improve performance in VW, and I would like to understand better the hardware factors which will help us achieve that. The largest issue that we have on a daily basis is navigation performance where very large PDFs are used as backgrounds. Our most common task is to extensively mark these up, or draw out 3D geometry based on these plans. The time taken to redraw the images on screen is painfully long, and makes fluid, efficient navigation difficult. Related to this, we often experience long waits before redraw in 3D views, when new symbols are inserted, especially ones with other nested symbols. Fluidly navigating through IFC files, often exported from Revit and Archicad, is also pretty painful. It performs better when we turn off portions of these models, as one would expect, but our work often involves the evaluation of facade lighting conditions, so this this not as practical. Our primary 3D navigation tools are 3D connexion mice, so long redraw times become especially jarring, as the fluidity these devices provide is broken. So as I see it, there are two dimensions of choice in both CPU, and GPU choices for these machines, which is what I am seeking advice on, given these particular goals. CPU: Scale out or scale up? Are these issues related to deficits in single, lightly multi-threaded, or heavily multi-threaded performance? Where does the VW roadmap point? Are high clocks, and high IPC going to be the biggest factors over the next several years, or is the plan to break up these draw tasks across many cores? AMD or Intel? Are their specific instruction sets being used which favor one architecture, or is VW largely platform agnostic? GPU Gaming performance or general compute? Should we be looking at gaming benchmarks for determining suitability? How well do these DX11/Vulkan tests translate to OpenGL performance? Should we be concerned about raw FLOPS for future releases over looking at current gaming results? AMD or Nvidia? Based on the other workloads, especially Disguise, we are generally leaning towards AMD (As GCN based GPUs are also used on the actual media servers), however if there is a significant performance differential in VW, its needs would take precedence. General Questions Is there a limit, imposed by how VW is written, to how smooth we can make this kind of navigation? Is this a situation where no matter what kind of hardware we throw at the problem, we are not going to achieve consistently smooth navigation with this kind of content? What other hardware factors may be at play? For reference, our current systems. 1. i7-5930K@4.3ghz, GTX-1080, 8x8GB@2666 DDR4, Samsung 850 Boot, and storage, 240mm AIO 2. i7-5930K@4.3ghz, GTX-980, 8x8GB@2666 DDR4, Samsung 850 Boot, and storage, 240mm AIO 3. i7-6800K, GTX-980, 2x16GB@2666 DDR4, Samsung 850 Boot, and storage, Hyper 212 I look forward to hearing the communities thoughts. Thanks!

I understand that part. What I need to know is where in the API can I extract the information that Renderworks uses. Renderworks has to have some way to calculate the illumination from these files. Can I query a point to receive an Illumination factor?

I also need to know the answer to this question.

Greetings, Are there any functions available to interface with IES files? I am trying to build out a plugin to be able actually take photometric measurements in Vectorworks. Our company needs to start doing grid layouts, and frankly, AGI32 is crap. Not for the quality of the calculations, but the interface is horrible. Anyway, are there any hooks into Renderworks, or anything else that would allow one to get the candela at a certain orientation and distance?

Greetings, My primary computer is a Mac laptop (late 2013 MBP). I have three primary work configurations, Mobile (internal 1400x900), home (1600x900), and work (1920x1080). I have set up 3 different workspaces which have all of the palettes sized correctly for the screen resolution. However, the positions of the pallets are not saved. How do I save the position of the palettes so that they will always end up at the correct on screen locations when I switch to that workspace?

Greetings, Long story short, I need to do a video flythrough of a model I have been working on, but with a full Google Earth environment. Let me preface this by saying that Sketchup will not export KMZ or KML files on my machine, and I'm not quite sure why (I have a request in with their tech support). Now, if I didn't live in Pittsburgh, and have to deal with hills, then a standard export from VW should work smoothly. However, GE interprets the bottom extents of the model as what rests on the ground. This means that unless I perfectly match the terrain, my model appears to be "melted" over the terrain. I have imported the terrain data from GE as a mesh into VW, and that much has worked fine. Now what I need to do, is use that mesh to cut the bottom chunk off of my model. I have posted a screenshot for clarification. What is the proper command to use this as the cutting plane? If VW can't do it, I can always reinstall AutoCAD and do it that way, but it would be really nice to know how to do this in VW. Thanks!

Greetings, To preface this post, I am an architectural/entertainment lighting designer and understand how light should look on both camera, and to the human eye. I have been having an issue with the rendering accuracy of the "Accurate Lamp" objects included in 2015. I am using a custom Renderworks environment, with no ambient lighting, as I am rendering an enclosed hallway with no ambient light. Lighting quality has been turned up to max, with reflections set in the mid teens. When using any of the predefined fluorescent tubes, or even creating one from scratch, I have to turn the render exposure to between 500-1000% just to be able to see the light they give off. The problem goes away when turning off falloff, but this rendering doesn't need to be pretty, it needs to be accurate. The client wants to know the result, imperfections and all. When using spotlight (light source, not Spotlight workspace) objects, the render out in a perfectly acceptable manner from normal 100% exposure. So now that I am trying to mix bare fluorescent sources and MR-16 downlights, I can not actually render anything accurately (simply tweaking the light output to make it "look right" is an unacceptable amount of accuracy loss). 2014 seems to behave normally, so I'm not sure if it's a 2015 bug. We really don't want to lose the new libraries though, but we could do the renderings in 2014 this time. I really hope that there is just a setting somewhere that is tweaked, because losing the ability to do accurate renderings in the newest version, and having to downgrade all of our files, would be a horrid amount of work. Anyway, that is all, thanks.

Oh hey, thanks! It's interesting to find out the usage patterns of other offices. Our office is 100% Magic Trackpads here, I guess I just assumed that was normal for the Mac crowd. Glad you guys are still thinking about it, despite us being a minority.

Greetings, I have now jumped aboard VW2015, and have really been enjoying it. The biggest thing that I had hoped for, but doesn't seem to exist, is an option to enable Apple complaint trackpad behavior. Apples guidelines state that panning should be accomplished by holding two fingers and dragging, and zooming should be accomplished by pinching. Anyone who has used the Mac version of Autocad, since v2013, will appreciate how much this improves drawing navigation. For anyone who is a mac user, and confused about what I am speaking about, I am talking about the trackpad use in programs like preview, or any of the iWork (or whatever they are calling it now) products. If there is a third party plugin, or new setting in 2015 which makes this possible, I would love to hear about it. Thanks!