Jump to content


Vectorworks, Inc Employee
  • Content Count

  • Joined

  • Last visited

Community Reputation

94 Excellent


About bbudzon

  • Rank

Personal Information

  • Location
    United States

Recent Profile Visitors

1,075 profile views
  1. This is actually a known bug in Vision. I'm not sure when it broke, but we have a fix ready to ship for Vision 2020 SP3. Keep your eyes peeled!
  2. As it stands currently, there is no way to do this. If this is a conventional fixture, it can be zoomed in Vision via the Software Console Palette. If this is a moving light, you will need to use DMX to change the zoom of the fixture.
  3. Sorry you're running into issues! You may have better luck posting this in the VW portion of the forums though as this subforum is specific to Vision previsualization.
  4. Leveraging High Quality materials in MVR for VW->Vision How to start Ensure that no procedural shaders are in use. Correct Incorrect Ensure that all image-based shaders are of a sufficient quality (72x72 is insufficient). Correct Incorrect All non-generic materials should use a reflectivity image and an appropriate blurriness setting. Brighter images will reflect more light. Low blurriness will create a sharper specular highlight. (Vision's default material resembles cloth or plastic with a slight shine. If you skip this step, your mesh will resemble slightly shiny cloth or plastic). Reflectivity Instead of using vertices to add detail to a mesh, consider using a transparency image or bump image. For example, apply transparency image shaders to a simple low-poly extrude to create a chain link fence. Or, apply a bump image shader to a simple low-poly extrude to create a brick wall. To give cloth a "textured" look, try using darker, noisy images as the basis of a bump shader. Transparency Bump General Tips Color shaders can use color. Color Reflectivity shaders should be grayscale (exception for metal whose reflectivity is the same color as its base color). Brighter images result in stronger highlights. Non Metal Reflectivity Image Metal Color Image Metal Reflectivity Image Blurriness values for reflectivity shaders should match the material in the real world. Metal is not blurry at all, but carpet is very blurry. Non Metal Reflectivity Image Metal Reflectivity Image Transparency shaders should always be black and white, (no gray). White will be rendered, black will not. Transparency Bump shaders should be grayscale. This shader should be mostly dark with some lighter shades for indentations. (If, instead, you use a mostly white shader with some darker gray areas to indicate bumps, then 90% of the mesh will be "indented". This looks odd when navigating around the scene. So, stick with darker bump images.) Bump Debugging Start by exporting MVR, changing extension to zip, and extracting. Examine all exported images. In Vectorworks, replace low quality or "broken" ones (typically resulting from a procedural shader or bad content). Extract MVR Find Low Resolution Textures Next, import the MVR in Vision. Navigate the scene with Ambient turned up and verify things look correct. Fix any issues. Correct Incorrect Next, use Render Specular to check reflectivity materials in Vision. Verify that all specular images are correct and display as expected. Fix any issues. Correct Incorrect Then, use Render Normals to check bump/normals in Vision. Verify that the bump detail looks right, and the expected colors are being rendered. Fix any issues. Correct Incorrect Finally, ensure that all materials have the proper specular power. 0% blurriness (i.e. shiny metal) =~ 1024.0 specular power. 100% blurriness (i.e. cloth) =~ 1.0 specular power. Metal Cloth
  5. I love this idea! We have always generally focused on prettier looking scenes with lower light counts as these same files were used for marketing material. But focusing on a performance friendly scene with many many lights is a fantastic idea. Let's coordinate on this. Just an FYI, I think the priority here would be large show file then medium then small. I like your, "Go big or go home" idea above 😉 If you can provide all three, that would be great. I'll look into seeing which ones we can get approved. 🤣 I think it's somewhat of a personal preference for me. I prefer the mobility of a laptop over a desktop. And don't get me wrong, my laptop is beefy. But a laptop will almost never outperform a decent desktop. And even though I do my primary development on a MBP, I have a Windows PC that is a desktop and it's card is nicer (but could still probably use an upgrade; tbh, I never thought to request one as I use it so infrequently). So, maybe saying minimal hardware wasn't completely accurate. I simply meant that your 2x2080Ti in SLI Thread Ripper is going to demolish my primary machine that I use for development 😂 I think anytime I need more power than my MBP or Windows PC can handle, I just borrow the TechSupport/Marketing machine which is at least 2x1080Ti in SLI. No thread ripper though 😛 No you are completely right! My example was poorly formed when talking about passwords as neither of those examples represented how software scales. So getting right to the point as Vision itself is a good example: (Note: I haven't tested this, strictly speaking. But this is pulling from my general experiences and memory.) If you ran Vision 2018 on an old machine and ran it on a new machine, you may get a 50% increase in performance. I feel this is being generous, but perhaps I'm wrong. If you ran Vision 2019 on an old machine and ran it on a new machine, you may get up to a 200% increase in performance. I expect given the right circumstances it could be much more (given how we leverage the number of textures the GPU supports). One last thing to point out is that Vision 2019 gave you the ability to control the way performance scales. So, in Vision 2018 you were stuck with the 50% increase when you upgrade your machine. With Vision 2019+, you are given many options to control the quality vs performance. This can be used to offset the poor performance of the old machine to bring it more "inline" with the newer machine. So all this being said, have things improved since 2018? Of course 😄 I don't think anyone is denying that. But to your point, that next leap in performance sure would be nice 🙂 What makes this tough is performing analysis on current code, and then properly executing a new design without breaking existing functionality. I still truly believe from what I've seen, the renderer is running very well. We never truly optimized the physics engine and I believe it is to blame. It will be a major overhaul to get it to be more performant, but I think as we investigate more we will find this is the right course of action.
  6. We do not have any, but this has been discussed in the past. I think one issue we kept running into was users wanting their files kept private. A lot of the files we get from users are on NDA and cannot be shared with other users, but are used for internal testing. Most of our developers run on fairly minimal machines. Tech Support and Marketing have access to one "beast" machine that we often take to tradeshows. This machine was a beast when we built it, but it is now becoming dated. I'm not sure the CPU/RAM that it has, but we had 2x1080Ti's in SLI in it at one point. No, but I like this idea a lot! I'm not sure how we'd go about approaching it, but that's neither here nor there 😛 Those limiting factors are not time and money. I know this is an extreme example, but passwords are very well encrypted. So much so that the fastest computer in the world would take years/lifetimes to crack it. The "issue" here isn't necessarily the hardware. It is the algorithm that is used to crack this password. For example, a dictionary attack may be faster than brute forcing. This is all on the same hardware, but the software imposes an upper limit on "how quickly the password can be cracked". Taking this conversation to Vision, look at Vision 2018 vs Vision 2019. It did not matter how much time/money/hardware you threw at Vision 2018, it just ran like garbage compared to the same machine with Vision 2019. So, while it may seem like the limiting factors of performance are time/money, this is only true to a certain extent. Eventually, you will hit an upper limit of the algorithm itself, and the issue is no longer hardware but the software design. One thing to keep in mind as well as that it was somewhat intended for these features to be shut off for real time renderings. The main reason we keep these features around is for "High Quality Render Movie/Still". Lastly, I do not disagree that Vision performance for real-time renderings needs to be improved. There are a few areas we can look at, but the one I've got my eye on is the physics engine (which is what handles panning/tilting fixtures, moving meshes related to DMX XForms, etc etc). I'd love to get some files from you guys that you wouldn't mind shipping as a demo file for Vision 2021. We usually record some DMX with it so a user without a light board can easily playback a showfile to see what Vision is capable of. The only other thing is finding a way to document hardware performance as well as driver performance. This will need lots of testing. Perhaps, the best thing to do here is come up with a "workflow" or "benchmark" for testing. For example: Load the sponza demo file Ensure all app/doc settings are set to default Playback recorded DMX Write down FPS at 0:30, 1:00, 1:30, and 2:00 (or something like that) The most important thing when doing these kinds of tests is ensuring that everyone is testing the same way. Having other programs like VW running in the background would affect these tests. So, we'll have to take it on good faith that no shenanigans like that are happening.
  7. I don't think this portion of the original post settled in for me until just now. tldr; Try applying a rotation in the Property Window to different items/parents/children in the Scene Graph to get different results. One of the items/rotations may be exactly the anchor point you need. One thing that is important, especially with MVR, is that you are working with the right item in the Scene Graph. There are various levels to an MVR object; an it isn't necessarily intuitive the way it is displayed in the UI right now. It may be that no matter what you rotate in the Scene Graph, it is not giving the desired anchor point. In this case, following @jweston's post/advice is sound! But let's look at some examples, because to be honest, I was surprised by the results! I thought that in order to get a truss to rotate around its center, a new layer would have to be created for the anchor point. But, after playing around with it more, I realize that at least for some truss this is possible without a new anchor layer! Look at what happens when I rotate on the various layers/geometries of a truss. Pay particular attention to the item selected in the Scene Graph, the rotation value in the Properties Window, and the result of that rotation in the viewport. Also, notice the MVR UUID in the Properties Window. A non-null uuid signifies the "root" of the MVR object: Let's also quickly show that same example with a sphere: Hopefully between this explanation and the various comments from our users about how they've solved this problem, it helps you out!
  8. I'm glad you're getting slightly improved performance! Tweaking the scene/fixture/geometry/render settings is always an interesting balancing act. I'm curious as to how much Haze Quality impacts the rendering speed. (And generally, run in realtime with shadows OFF. Only enable shadows for rendered movies/stills. This is the default behavior.) One last "power user tip" that a lot of people aren't aware of; there is a Force Emissive flag for fixtures that prevents beams and surfaces lights from rendering. When this option is enabled, all that is rendered is the lens and the bloom effect for that lens. Fixtures that have multiple light emitters can really kill performance depending on how many emitters there are and how many of these fixtures are in the scene. So while the Force Emissive flag isn't very helpful when the light is being used to, say, wash a stage, it can be very helpful in certain instances (such as generic blinders). We often use this flag internally for Nexus 4x4's and the like 😉
  9. I like the 2020 haze too 🙂 It may just be that you turn it on for your final renderings but don't use it for real-time preprogramming. FWIW, you should get much more than 9/10FPS given you use the same default settings I used in my tests. My machine is OOOLLLLD. Like, going on 5 years old 😛 I have an AMD Radeon R9 M370X with only 2GB of memory. Your 1070Ti should destroy my graphics card 🤣 One thing I would do is ensure you are running with settings similar to my own. All I did was open your v3s, then launch the application and document preference dialogs. In each, I selected <Default> from the saved sets dropdown. This will get us "on the same page". But again, your 1070Ti should well outperform my M370X. If this is still not getting you the performance you want, I would suggest tweaking the default application/document settings to get the performance you need. This was a big improvement to Vision, as in the past you had no ability to adjust settings to tweak performance/quality. As we've already discussed, setting Haze Texture Intensity to 0% helps substantially. Adjusting Haze Quality will make a big difference as well. Think about playing with things like Resolution Quality, Render Shadows, and Shadow Quality as well. My only suggestion here is to be forgiving of quality in real-time. Vision can get the HQ renderings in a rendered movie/still. As far as purchasing of more powerful hardware: It's hard to say if upgrading to a 2080 will result in enough performance gains to be worth the cost. We've had some customers really ball out on a machine, only to find that there are limitations in Vision's code holding back the hardware. This probably seems obvious, but in general, no software can scale infinitely to leverage all hardware. There is always an upper bound on the code design itself. We generally find that Vision leverages as much hardware as you can throw at it (ie; 2x1080Ti's in SLI performed almost twice as fast as a single 1080Ti). But again, there is always an upper limit as to how much hardware software can use.
  10. One last thing! It always sucks when merging an MVR into an existing document in Vision wipes out certain changes you've made inside of Vision. I highly recommend once you start applying changes in Vision that you save to v3s so they aren't lost! But more importantly, that you only export items from VW into MVR that need updated moving forward. This means that only those items will get recreated in Vision when you merge the MVR. This should hopefully reduce the amount of "crap, merge mvr wiped my xforms" comments 😛 Edit: Also, as many may not know this, if you ever perform an MVR merge and it breaks something, just hit Undo once! It should undo everything the merge did and get you back to a good state 😉
  11. So, reporting back as after discussing with our engineers, I realized I provided some incorrect information in the post above. Haze Style None does NOT EQUAL 2019 style haze. Rather, it is closer to the 2018 style haze that used slices. Haze Style High-Quality 4D Haze - Half Resolution with Haze Texture Intensity set to 0% is roughly equivalent to 2019 style haze. After running a proper apples to apples comparison between 2019 and 2020, both are getting similar framerates as I expected. 2019 is getting roughly 10FPS. 2020 is getting roughly 9FPS. If you have any questions about Haze Style or Haze Texture Intensity, please let me know! I will do my best to answer.
  12. This is actually an issue that has been coming up a lot recently, but one that takes a lot more work to implement in both VW/Vision than I'd have imagined. What we'd like to do, is get some UI/UX in VW such that you can set everything up there and send it over to Vision via MVR. Now, I'm not saying it wouldn't be nice to have this same UI/UX in Vision! I think that is a requirement as well as you very well may need to make adjustments in Vision once things are moving around. I digress; due to the way Vision is designed, and due to the way VW is exporting MVR, there is a workaround but it is not simple nor straight forward. But, it works. Essentially, you want to make a new layer in the Scene Graph. This layer, by default, has an origin of (0,0,0). You can then drag'n'drop a group of items that move together (say a truss and all the fixtures on it, or even multiple stage elements that happen to move together) into this newly created layer. Once this is done, you will need to reposition all of the children inside of this layer, and you will need to reposition the layer itself. The last step is applying the DMX Rotation to the layer you created as opposed to the moving elements themselves. Since this will rotate all of the layers children, this should accomplish what you need. The hard part about this workflow is the positioning of the layer and the children inside of it, and getting that just right so that the elements rotate around the desired anchor point as you've described. Either way, hopefully this helps and this is definitely something we're trying to solve sooner than later!
  13. (Posting here instead of PM so other users can benefit from this information) Ahh, one thing I forgot about that was an enhancement request implemented in 2020 is textured haze. From the looks of it, the majority if your performance issues are caused by haze as opposed to shadows/surface lights/etc. So let me break this down a little bit so you can understand how to get better performance in 2020 (and potentially even better performance in 2019). It does appear that there is still a regression somewhere that we need to track down. But, I want to help you out as much as possible in the meantime. So, in 2019, you could use the older 2018 legacy style "sliced haze" (called Low Quality Haze Texture in 2020) or the new 2019 style haze (called Enhanced Volumetrics in 2019). The 2019 style haze was software ray traced, but did not allow for any texturing. In 2020, we added 4D texturing to the 2019 style haze (we also unlocked a "full resolution" mode, which should generally only be used for rendered movies). I think this could be at least part of the performance issues you are seeing. But we need to investigate further. When I run your file with default document and application preferences on my old old MBP in Vision 2019, I get roughly 10FPS just selecting the sunstrips in the Scene Graph. When I run your file with default document and application preferences on my old old MBP in Vision 2020, I get roughly 1FPS. This is because the default document preference for Haze Style is the new 4D textured haze (the texturing aspect is controlled via the Haze Texture Intensity field). In order to do a better apples to apples comparison, we should try this same 2020 test with Haze Style set to None (as this is the equivalent of the 2019 style haze). In order to do a better apples to apples comparison, we should try this same 2020 test with Haze Style set to High-Quality 4D Haze - Half Resolution with a Haze Texture Intensity set to 0% (as this is roughly the equivalent of the 2019 style haze). When I adjusted the 2020 Haze Style to None my FPS bumped up to 5FPS (a 500% increase in performance from 1FPS! hahahh). This is still not the 10FPS I am seeing in 2019, but substantially better than the 1FPS we are seeing in 2020 with default settings everywhere. This is the thing I want to investigate further as in theory 2019 and 2020 should perform nearly identical in this case. When I adjusted the 2020 Haze Style to High-Quality 4D Haze - Half Resolution with a Haze Texture Intensity of 0%, my FPS bumped up to 9FPS (a 900% increase in performance from 1FPS! hahahh). This is still not the 10FPS I am seeing in 2019, but it is so close that I believe this is working as designed. Lastly, I used a Haze Quality setting of 30% in all of these tests above. Generally, during my development and due to me having an older machine, I run with this set to 1% instead. Adjustments to the Haze Quality can make a big difference in render times. Since I noticed that the majority of your performance issues are caused by haze, I thought I should mention the Haze Quality application setting. So, lowering this setting in 2020 (or even in 2019) should result in better performance. I will try to report back with any new information we find!
  14. I find this part particularly interesting, as in theory not much in the backend rendering has changed between 2019 and 2020. Would you mind posting what versions of each you are using? ie; 2019 SP4 and 2020 SP2? Lastly, if you could post your Vision file that would be great! We can play around with it internally to see where things are breaking down.
  15. I could be wrong, but I think @BrandonSPP told me about this at one point and I looked into it. I'm not entirely sure that we have control over the code that spawns this dialog. I'm not sure why it spawns, but @BrandonSPP mentioned way back when that despite this dialog, MANet always seems to work just fine? I'll double check and see if a ticket is opened up against this. At the very least, we should have this documented in our bug system so we have a more definitive answer when this question pops up. Either way, hopefully everything is working for you now!


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...