Jump to content

bbudzon

Vectorworks, Inc Employee
  • Posts

    505
  • Joined

  • Last visited

Everything posted by bbudzon

  1. Thank you for sharing this!! I'll start working with some of our teams internally to see if we can figure out what might be going on. Please provide us updates if/when you have them and I will try to do the same!
  2. Most of your ROOT/Global Document settings seem good! So, I don't think that is the issue. Digging deeper, I decided to run some more tests. In this test, all I did was open your V3S, select the S4 36deg group, and assign them a gel of 0, 0, 255 for full blue. This was the result: So, that seems correct and what I would expect! Perhaps, you can try this test and at least make sure this works. I started looking around in your document more and noticed a few lights that look like this: This screenshot has that "steel blue or medium lavender" color to it that you had in your original screenshot. Upon further investigation, it became evident that the colors assigned to these fixtures are the cause: I'm not sure if you just entered these RGB values incorrectly or if our stock content is incorrect. But, either way, adjusting some of these values should hopefully fix your issue. I'll work with our content teams to determine if our stock content has the correct RGB values.
  3. Hmm, that is odd! A quick test on my end and I cannot reproduce. It may be tied to some of the document settings. Perhaps, you can try recalling the defaults? If you can post your VSN that may be helpful as well.
  4. @DBLD, I thought I had responded to your initial post. I just reached out to our content guys to see if I should open a ticket, but one was already opened and lo and behold, I've been informed that the issue is resolved! I think we are still working on verifying the fix, but if you run a Library Update in Vision to pull down the latest litfiles and content, that should hopefully take care of your issues!
  5. It is my understanding that dpi only has an effect when printing the image. So, you should be good to make the image whatever dpi you'd like. To the best of my knowledge, only the resolution will have an impact on the renderer.
  6. Not a problem at all! These are items that notoriously increase vertex count and unnecessary amount. Some users will just not send them over. Some users will use a single large box extrude to emulate a truss. Some users make custom symbols for trussing that are low poly count and "realtime render" friendly. So, it does make sense that not sending truss (and crowds) to Vision helped. But again, Vision tries to be very good about large vertex scenes via it's deferred rendering technique. So, I'm also not surprised it didn't make a huge difference. It makes the largest impact when shadows are enabled, but most only run with shadows for rendered movies/stills. Great! As a test, I inserted a Varilite VL4000 Spot 16bit and a Martin Mac III Performance Basic into a vision scene. It took me a while to figure out how to control these from the light board, but I once I figured it out I had no problem getting gobos to render in either fixture. One thing you may need to keep in mind for the VL4000 is the "16-bit linear control of edge functions". This 16-bit value straddles channels 6 and 7 (6 is high byte, 7 is low byte). When I have the edge control set properly, I get the following rendering: If I leave the edge control set to 0% on channels 6 and 7, it results in a very "fuzzy" gobo that is almost indecipherable from an open slot: So, please make sure you are controlling the edge function properly. You never said whether or not you tried setting Haze Texture Intensity to 0% or not. When this value is between 1-100%, it enables "4D Haze" which can cause performance issues and is generally reserved for render movies stills. We are always working to improve the application and have some really neat things that will ship with 2022 that will make it easier to get the performance/quality that Vision is capable of. One issue we've seen over the years is that many times the issues are user error. However, we take responsibility for this as our settings are not intuitive. Keep your eyes peeled with Vision 2022 πŸ˜‰
  7. In most cases, 256x256 or 512x512 will be all that you need. I find it is a good balance between performance/functionality and quality. Basically, you want the image to be as small as possible while not degrading the quality visually. If the object in the scene is very small, maybe 128x128 or 64x64 would be enough that the quality would still appear sufficient or good. The reason you want to use the smallest image possible while maintaining visual quality/fidelity is to help performance. Increasing the texture image resolution to obtain better quality has diminishing returns. So, for a small object in the scene, a 16x16 image will probably look significantly better than an 8x8 image. But, a 4096x4096 image may not look visually any different than a 64x64 image as the object in this example is small. Similarly, if an object is not the focus of the scene, it may be okay to use an 8x8 image instead of a 16x16 image (or a 256x256 instead of a 512x512) because it's just not that important and the eye will not be drawn to the unimportant item anyway. It is all a big balancing act; tis the world of a realtime-engine content creator. One last pro tip; GPU's are optimized for powers of two. When possible, try to stick heights and widths that are 1, 2, 4, 8, 16, 32, 64, 128, 256, 512.... you get it πŸ˜›
  8. It sounds like you've done a lot and have learned quickly! Very impressed! It's hard for me to say why the performance of your file is subpar. Your settings seem pretty sane for a file with 600 lighting devices and you've already discovered the Force Emissive feature which can help with fixture count drastically. You also mentioned that this file has performed well in the past and that only recently have you run into performance issues. So, I am hopeful we can get you back to that enjoyable performance. If I had to guess... I'd say that your biggest hit to performance is one of the few you have not yet mentioned; Haze Texture Intensity. I'm not sure why this would have changed, but if this document setting for haze is set to anything between 1-100%, then Haze Texturing will be Enabled. This is the 4D portion of the haze, if you've seen that in the UI. By setting Haze Texture Intensity to 0%, it will disable the 4D algorithm which provides an even wash of haze for beams of light and saves significant amounts of time in the rendering engine. If this does not help, maybe we can exchange files and screenshots to see what may be going on. Tweaking Vision settings is definitely something I am most familiar with πŸ˜› In regards to the time to change Texture Quality, there is a lot of different things going on here that most users aren't aware of. For starters, any Texture Quality that is Medium or above uses a concept we call a Dynamic Cache. Any Texture Quality that is Low or Very Low uses a concept we call Static Cache. If you switch from any Texture Quality that is Medium or above to Low or Very Low, we must essentially reload the file clearing out the dynamic cache and building the static cache. This is true in the reverse direction as well. Changing Texture Quality from Low to Very Low or Medium to High would not trigger this "full rebuild" of the static and dynamic caches. My guess is that the some odd hour you are waiting when changing to Low or Very Low is spent on a progress bar for rebuilding the static cache. If the static cache is taking this long, it tends to imply that there are many many vertices in the scene; ie a very high poly count. Vision leverages a technique called Deferred Rendering which generally nullifies any performance hit from high vertex counts. This was important for Vision as it's main "input" is meshes from VW. And VW being as detailed as it is, often includes meshes that are not truly designed for realtime rendering. But, even with this deferred rendering technique, there is a limit and certainly you will always get better performance when the vertex count is lowered. The biggest offender of high vertex counts is the geometry that VW uses for truss. One way to determine what is causing the static cache rebuild to take a long time is to only send over bits and pieces from VW to Vision, checking as you go. One other fairly quick test that helps check rendering performance (but not load time / rebuild performance), is simply unchecking the Visible flag for an entire layer. This obviously will not decrease load times or make the static cache rebuild any faster. But, if making a layer that contains a bunch of trussing invisible drastically improves render speeds, it is likely the case that this layer contains more vertices than is necessary. In regards to your fixture questions, I may need to call a content person to this topic πŸ˜‚ My best guess is that for the VL4000, the wrong profile/personality is being used on the light console or in Vision. Try to make sure the right modes are selected for the device and that the DMX Footprint (or Num Channels) matches. For the Chorus Lines, make sure that the broken behavior is not tied to the Force Emissive flag. In truth, the Force Emissive flag was a hack written by engineering in an attempt to lighten the content teams workload. Normally in Vision, if a fixture causes performance issues, the content team would create two versions of the fixture; the real version that emits light and beams and an "emissive" version that only the lens will glow. Engineering found a way to automate this for most fixtures via the Force Emissive flag; so that the content team only needs to create the "real" version. If the Chorus Lines are broken for other reasons, we may need to correct content files or engineering source code in order to address the issue. Hopefully some of this information helps. Please provide updates and let me know how things are going. Me, being a software engineer, can mostly help with things like performance / quality tweaking settings and workflow related things like how multiple selections work, faster patching, RGB meshes, and such. Tackling problems like gobos not working or Vision not seeing DMX can be much more difficult and may require getting IT, Content, and/or various other departments involved.
  9. I wanted to run some tests once I got back from break. It appears in my testing that the patch information comes from Vectorworks to Vision just fine. I used both GDTF and Litfiles in my MVR testing. One thing to note that may be confusing you, GDTF fixtures will not show up in the Patch Window in Vision. This is a limitation of Vision's GDTF implementation and something we are looking to resolve. That being said, when a GDTF fixture is selected, you should see proper Universe/Channel in the Properties Palette.
  10. Unfortunately, we have not been able to reproduce these issues in house and are still working on tracking the issue down.
  11. This topic more involves the quality of rendered meshes and how to setup RenderWorks textures in VW; not so much rendered light. That being said, there are a few things you may try any one or any combination of the following: Increase Haze Quality Increase Resolution Quality Increase Surface Light Quality Use Haze Style None, Low-Quality Haze Texture, or Low-Quality 4D Haze (creates a sharper look, but looks bad when pointed at camera) Use Haze Style High-Quality 4D Haze - Full Resolution (usually reserved for rendered movies, can cause performance issues) Note: When using 4D Haze Styles, Haze Texture Intensity can be set to 0% to increase performance.
  12. There may be some reason why this is happening. I can at least explain how it works. There are also some improvements you may be able to make to your workflow that will make things easier and look/perform better. Send to Vision uses the older ESC file format. You should consider using Export MVR instead. Here is a good topic covering the benefits: My guess is that there is some piece of mesh way off in no man's land. What Vision tries to do whenever opening (not merging) a non-V3S file format is calculate the bounding box of the entire scene and then fit that into view. If you are not aware, the Fit to Objects tool is incredibly helpful for quickly navigating to an object(s) of interest. This often has to do with the Look At Point being off in no man's land. The Fit to Objects tool workflow helps with this as it ensures the Look At Point is near the things you are "looking at". This is what I would expect. But, this will only work properly if there is no odd ball geometry off in no man's land. You can quickly "break" this new file by putting an extrude way far away from the rest of the scene. One way you may be able to "diagnose" your original file is by selecting the New Layer underneath ROOT in the Scene Graph. This will draw a bounding box for the entire scene. If this bounding box is not what you expect, you can select various items in the Scene Graph until you find the "offending" item. And I think a lot of people are not aware of the Fit to Objects tool in Vision. I find it quite critical to navigating the scene quickly and intuitively. Without the Fit to Objects tool in your workflow, a conscious effort must be made to understand where the Look At Point is and how it behaves. Fit to Objects alleviates much of this need. Hope this helps!
  13. I had a chat with content and realized why things are being done the way they are. The "quickfix", as I stated previously, was to simply disable the Color Temperature field. This was intended to hold us over and allow for a more intuitive UI until we could investigate a real fix. What I'm investigating now is how we can handle both a Lightmap AND a Color Temperature in Vision source code / rendering engine. The Lightmap provides certain effects that content cannot remove without breaking the fixture. So, this must be handled in code. Luckily, the ground work is going pretty well. Whenever there is any update on this, I will do my best to post them here! @DBLD, if you need a "fix" sooner than this, you can kind of hack things up in 2021 to work. I was hoping to avoid posting this, but I hate to leave you hanging. There is a par.png file included with Vision installations. I would back this up before you do anything. But, if you open the par.png in paint / photoshop / gimp and paint the white sections an amber-ish color, you'll get closer to the look you are going for. Please note; this may break other things and may need to be manual "undone" by hand when some of my fixes ship. Perform this "hack" at your own discretion.
  14. So, just an update on this: Just a few lighting devices in Vision leverage a concept called a Lightmap. This is something entirely in the backend and something that is not seen or editable by the end user. Anytime that a Lightmap is present, Vision ignores the Color Temperature field and uses the Lightmap image instead. Part of the issue being reported is that Vision was not making it clear to the end user that this was the case. The Color Temperature was filled out with a value that didn't really make sense and it was editable when it should not have been. The solution is in Vision's code base we need to handle populating the Color Temperature field as read-only when a Lightmap is present. This way, it is clear the field cannot be modified as it will have no effect. So, @DBLD, the solution to your problem is to use a different fixture / fixture mode. If one does not exist that does the Color Temperature stuff you need, you can request it through the Fixture Request form for Vision. I'd have to check with our content team, but in theory, we could provide a molefay that does not use a lightmap and therefore would have an editable Color Temperature field that would allow you to set it to whatever you want.
  15. Note: I made a small change to the guide. In the past, I suggested that Image be selected for Transparency shader if you want to send this to Vision. This did work with Vision well, but it caused issues in VW. Now, you should use Image Mask for the Transparency shader. This allows both VW and Vision to render properly.
  16. A new "cut" of Vision 2021 SP4 was just released. This includes the hotfix for the MA3Net error.
  17. Ahhh, I just heard back and this is indeed a known reproducible issue with SP4. We are working on getting a fix out ASAP. For the time being, use another DMX Provider or if you can fall back to SP3. It's always hard to predict how quickly/easily something can be fixed, but I'm hopefully that this will be resolved sooner than later πŸ˜‰
  18. I'm not aware of any significant changes to the MA3Net stuff in the SP4 release. Did this work for you in SP3? Either way, this is the first report I'm hearing of this and I will make sure that the MA3Net developer gets this report. Seems like this should be an easy one to reproduce!
  19. DM me the file just in case it is something obvious. What we have found is that this issue is very difficult to reproduce and has been very difficult to find in code as a result. Steps to reproduce, while difficult, are usually the silver bullet for getting problems solved quickly.
  20. If you have access to JIRA, you should file it there. The advantage of having this access (which is restricted to BETA users I believe) is you kind of get updates on the report and will see when it has been resolved and at what build number. Otherwise, I'll make a note to open a report in JIRA myself; one that references this forum post. It's not clear to me yet whether or not this is an issue in code or in content. Content issues can be fixed "mid-release". Code issues require a Service Pack. We'll try to take a look sooner than later!
  21. FYI, if you have a LOT of fixtures, sometimes turning Render Fixtures to Off instead of Black can help performance (it reduces vert / poly count in the scene essentially by "skipping" fixture geometry). Also, if you have the time to render a movie out with pre-recorded DMX, setting Render Fixtures to On can give a much more realistic look (one where one fixture can hit another fixture with light and that fixture will reflect like properly instead of just rendering black). Food for thought! Glad you found the setting you needed to adjust πŸ˜‰
  22. I'll let the team know. It seems to usually be tied to those "dual monitor" setups. Quick question, what resolution are your two monitors running at? Are both monitors "horizontal" or have you physically rotated one to be "tall"? Do you know if these monitors are HighDPI or not? If so, do you know what scale is being used (usually 0.5, 1.0, 2.0)? Thanks!
  23. There was a bug introduced into MVR export at some point. Anytime Transparency shader had an image or image mask, it would use that as the main color image. This was evidenced by the images that got exported, as you've discovered! Very detailed report, much appreciated! This bug was fixed in VW2021 SP4. It should be available now! See if that takes care of things for you πŸ˜‰
  24. I had seen this post and am not πŸ’― certain what is going on. There is a lot involved in your workflow, but you did a fantastic job detailing all of it and it appears as though you did a fantastic job of ensuring that everything was accurate down to the pixel. I did have some comments I was "holding on to" because I didn't want it to appear as though I was simply not addressing the issue. I was hoping to be able to find time to investigate with the entire VW Vision team and come back with something definitive. One comment was related to the text above. If you are scaling the image in VW in such a way that Vision does not pick up on the change, then we should try to find a different way to scale the image. One such way is by editing the Renderworks Texture directly. There are probably many other ways. We will need to investigate this more as ideally everything would work regardless of "how" you scale an image. Another comment was that "Capture Source Name" is entirely ignored at export time. This is why you don't notice it in Vision. I believe this was put/kept here mainly to leave yourself notes in the VWX document. However, the "Capture Source Number" will come over to Vision as "1.cap", "2.cap", "13.cap", "52342.cap"; whatever number you put in there will be used as a unique integer identifier in Vision for "Video Inputs" (which can be NDI or UVC). One of my last comments was related to 1920x1080 vs 640x360 NDI Streams. In our research, most users are not cropping NDI Streams and most NDI Streams are not so highly detailed and so large in the scene (as viewed on your desktop/laptop monitor) so as to require 1920x1080. NDI supports high and low bandwidth modes and for a realtime vizualizer low bandwidth is preferable for performance reasons. This is why low bandwidth is the default and likely why you are ending up with a 1920x1080 source stream ending up in Vision as 640x360. If you would prefer the source resolution to appear in Vision, simply select the High Bandwidth radio button underneath the NDI live preview. Because you are cropping and doing other very detailed things, I think this is a perfect example of where High Bandwidth is indeed acceptable. Again, in most cases, you should use Low Bandwidth if you can. I've not had issues with sending multiple NDI streams to Vision. However, it may not be as evident that only Vision Unlimited license allows for more than a single NDI stream. All in all, I'm not sure that any of this will resolve your issue. Users may find it informative at the very least. My hope is that this is merely us not having accounted for some workflow and that another workflow/workaround would allow things to proceed. But it is very possible there is just some issue/deficit in the core code when handling these kinds of things. It might take some time, but I am hoping we will be able to figure this out in the long run and ensure that we support this workflow moving forward.
  25. That is unfortunate. If we could find the steps to reproduce the issue in-house, we may be able to more easily find the issue in code. πŸ˜‚ Yea... I believe that on OSX a force quit will always trigger the safe mode dialog on next start. However, WIndows Task Manager and End Task does not seem to accomplish quite the same thing. There is not. However, I think we are getting to a point where it makes sense to expose a "force safe mode on next boot" button in the Vision Application Preferences. Depending on how things end up working out in code, this may be able to be a "clear all user settings" button (more similar to VW). Any information you can provide for reproduction would be ideal. I'll see if I can get QA to take a look. In the meantime, I can at the very least start proposing that we expose safe mode / clearing user settings in a more user friendly fashion πŸ˜‰
Γ—
Γ—
  • Create New...