Jump to content

bbudzon

Vectorworks, Inc Employee
  • Content Count

    450
  • Joined

  • Last visited

Community Reputation

121 Spectacular

4 Followers

About bbudzon

Personal Information

  • Location
    United States

Recent Profile Visitors

1,514 profile views
  1. Just to be clear, the parameters are 24bit (coarse/fine/ultra), not 32bit (coarse/fine/ultra/uber). It may very well be that this misunderstanding is what is causing the "steppy"ness. I feel our absolute cameras are much more "granular" than our relative ones, fwiw. Yea, I hope we can get the absolute cameras working for you! The are a big improvement. And thank you for all of your feedback regarding the relative cameras! I will work with our team on correcting any issues with the DMX Sheet and discuss adding additional columns for the reasons you have provided. If you wanted to share your profile, we could take a look at how you did things!
  2. I can work with our team to work on updating this so that it is more informative. There's a lot of implication here and I think it can be more clear! Thanks! The original purpose of using smaller values here was to allow lesser hardware to render something it would otherwise be incapable of. Generally speaking, the more GPU VRAM you have larger this value can be. It shouldn't need to be. The intent was the Render Still's Resolution would determine the output aspect ratio, regardless of the Render Buffer Size selected. The Render Buffer Size merely breaks the rendering down into smaller pieces so as to be more efficient (at the cost of time). This is somewhat complicated but I think there is an example for VW users that will make sense here. You know how when you render a scene out in VW using RW, it kind of comes in one "square" at a time? Vision's Render Buffer Size for stills and movies gives you control over how large each "square" is. If the "square" at least as large as the entire viewport, then only one square is needed (this is what is done in Vision for realtime). Using one "square" for rendered movies/stills is ideal, but requires higher end hardware to achieve. Based on your screenshots and how you are describing the camera position/FOV, I think this a bug. I'll have to look into this further and see if we can determine the cause. Bloom not working is a current limitation of using smaller Render Buffer Sizes. With our current design; if you'd like bloom in a rendered movie/still your Render Buffer Size must be at least as large as your output Resolution. (It seems you've already figured this out! 😉 ) This is often caused by having a complex scene while having your settings too high. It seems that Vision was able to render the first half of your DMX Recording, but more lights likely kick on near the halfway point triggering longer renders and an eventual crash. To test this, you could try rendering out only the first 25% of the DMX Recording by using the start and stop times. It seems to me like this would succeed. In order to render your full DMX Recording, you may need to lower some of your application/document settings and then using "<Active Settings>" when rendering the movie (do not customize). This should ensure that the Render Buffer matches the output. There are some general steps I go through at times when working with Vision users struggling with render still/movie. If you're having trouble rendering movies/stills, try using "<Active Settings>" and a low output Resolution (or an output Resolution that matches your realtime Resolution Quality). If you're still having trouble, try lowering your application and document preferences significantly; to the point that the output is borderline unacceptable. This is simply a test. If the test passes and the movie/still renders out with all settings floored, then we simply need to start increasing the settings by small increments; testing as we go. Increase the more important settings first. Note that toggling shadows on/off makes significant impacts on the hardware. We're trying to find a balance between your scene, your dmx recording, and what the machine can handle. If the test fails and the movie/still does not render out with all settings floored, then something is likely very wrong. Odds are, any hardware that meets our system requirements should be able to handle this. It may be that the scene is large enough that Vision is struggling regardless of hardware. This can be tested by rerunning the test in a smaller file. Again, it's just a test; the smaller the better. If this small file test also fails, it would almost have to be a bug in the code. When things are boiled down like this, we can sometimes provide a workaround until the issue can be resolved.
  3. I've actually been noticing this lately. I also noticed that some MVR Objects seem to be coming in with 0 UUID. It's hard to say right now, but I will try to investigate. MVR Objects that are identified in the MVR as a truss get an override material of "Silver" by default. My guess is that some of your truss items are being properly identified in the MVR Export VW-side and some of them aren't; presumably due to the tool that was used to create the truss or any actions that were performed against it after creation. However, if you set the Truss Material to "Imported" it should not override any materials and all truss should (in theory) look the same. If rather than dropping the material override you'd like to know how to apply the HQ Silver Truss Texture to all trusses after import, let me know and I'll make a little post here about it 😉
  4. The current version is Vision 2021 SP2 (2.1 technically, I believe). SP3 usually releases right around this time. So, again, keep your eyes peeled in the coming weeks 😉 I apologize for the inconvenience.
  5. After playing around with your file some, I can reproduce the issue. The good news is that it seems to work fine in Vision 2021 SP3. So, keep your eyes peeled!
  6. Ahh, I didn't realize it was that large. We will likely have to break it down into smaller pieces to see if we can find the culprit. This should definitely help with reproducing here locally. Would it be possible to share a link to dropbox to the VWX? Given the size of it, it may not upload to the forums. But, having a chance to play around with that file and see how things are setup in the VWX will help gain a better understanding of what may be happening. One test that often quickly eliminates importing as an issue is ensuring that the MVR imports into a blank document "the same" in VW and Vision. If they are broken in the same ways, the issue is likely at export time. If they are different, well... I tend to blame Vision because I work on that code and so I can investigate/fix it 🤣
  7. This is definitely odd! And it is hard to say if the issue is import/export side. In general, I recommend avoiding ESC entirely. See the link below for reasons why: Moving on: Try exporting the entire VWX as a single MVR and import that into Vision. See if this fixes the issue. If not, MVR is constantly getting updated and ESC is moving more towards legacy. This is a blessing and a curse for ESC. While ESC is generally a much poorer format than MVR, it may prove to be more stable. Try exporting the entire VWX as a single ESC and import that into Vision. See if this fixes the issue. One last thing that we can try to do to narrow down the issue is: Export the entire VWX as an MVR. Create a new VW document. Import then MVR into this blank VW document. See if things are correct or broken. Only other tip that may help us narrow this down is exporting the entire VWX as a 3DS file. This obviously will not transfer fixtures as fixtures (they may just be geometry). But, we can use this 3DS file to import back into both VW and Vision (use new documents when importing). This might help us determine if the issue is import side or export side as well. Lastly, posting your VWX here for us to test internally may prove useful. When we can replicate issues it is much easier for us to find out if there is a bug in the code 😉
  8. I would highly recommend checking out some of the demo documents provided with Vision for playing around with the new version and getting familiar with new features! We tried to provide a variety of examples with various settings/features. We've also included a DMX Recording that you can play back to see what a show might look like. (Do keep in mind that you may need to adjust some settings in order to get a good balance between performance and quality.) We've made a somewhat conscious effort to ensure that Vision first and foremost is fast at rendering lights in real time, that it look of a sufficient quality, and that necessary protocols are (such as NDI) are supported. Unfortunately, this means that Vision's modeling tools and features can be lacking. You've likely found a bug with our sphere/box/cylinder tools. I can take a look at these tools in the code and see if we can figure out what is happening. Where Vision really shines is when working with MVR, which is generally exported out of a program more centered around modeling such as Vectorworks. If playing around with the demo files provided with Vision is not helpful, please let us know! We can try to improve them in the future. In the meantime, my suggestion would be to try to bring some simple models into Vision via 3DS/OBJ/MVR. You can use Vectorworks to generate an MVR/3DS/OBJ, but you can also find sample 3DS/OBJ files online. (Vision unofficially supports more formats, but you will have to try them out and see if they work for you or not as we have not performed enough testing to officially endorse these other formats.) I hope this helps!
  9. By the way, the bug I found was related to two layers sharing the same name nested at the same level in the Scene Graph. Vision was seemingly getting confused as to which layer was which and inserting fixtures into the incorrect layer. This was obviously noticed with copy and paste; as pasting a layer next to the one that is copied would result in a layer which is identical in every way including in name (ie; "Forum Fixture"). One "workaround" is to copy the source layer, but changing its name before pasting (ie; "Forum Fixture" to "Forum Fixture 1" or "Forum Fixture 1" to "Forum Fixture 2"). You can continue with this process renaming and pasting until you have as many "custom fixtures" as you need. I apologize for this buggy workflow. I've managed to find where this is happening in the code and have a simple fix pending. I'm not sure when it will be able to ship. But know that in the future, this workflow with copy and pasting a "custom fixture" like this will work better.
  10. Glowing textures in Vision do not give off light. However, increasing the dimmer on the fixtures "inside" of this custom fixture will give off light and this light will "hit" a wall as you'd expect. https://app-help.vectorworks.net/2021/Vision/index.htm?#t=2021_Vision%2FVision%2FThe_Properties_palette.htm%23TOC_Object_and_fixturebc-2&rhtocid=_0_6_1_1 Take a look at the Emissive category of a mesh object. This category contains Fixture Type, Fixture Candela, Fixture Universe, and Fixture Channel. All of these must be set to proper values in order for the emissive (or glow) mesh feature to work. (Note: The Cast Shadows setting I mentioned prior is also documented on this help page in case you need it.) Not a problem at all! Vision has it complexities but it can also be deceivingly simple at times. There are a lot of features inside of the software. It's usually just a matter of knowing where to look! (Note: We've tried to do a really good job at ensuring that all supported features are documented in the help. I'd definitely recommend trying to reference it whenever possible!)
  11. 👍 Not a problem at all! Ahh, I see. Based on the variety of issues you are seeing, the red beam not interacting may be more of a coincidence. Either way, none of it is desirable 😂 So long as the textures folder is next to the v3s, that should be all that is needed. It may be that there is some issue tied to the Texture Quality that we are unaware of. You may try various Texture Quality settings to see if that resolves the issue (and if so, report back as I had not tested that yet). Our default setting is Medium. High and Very High can be used when HQ Textures are desired. Low and Very Low enables an often unused (and therefore less tested) feature involving "static geometry". In theory, grouping that static geometry together would help with performance. But, it can also be a bit more finicky at times (when compared to, say, Medium). One potential issue with these machines is the integrated graphics card. Even though we have found that we often can run on integrated hardware, Vision's demands at a foundational level (meaning the simplest of files) has caused issues with them in the past and present. As we continue to push Vision further and further, integrated hardware will become less adequate. When we state minimum system requirements, it is often because this is the hardware we have tested on and believe it to work best (providing tiers of performance). Due to the current technical demands of Vision and the hardware we have tested on, we have set our minimum system requirements to a dedicated graphics card with 2GB of VRAM (we recommend 8GB of VRAM on the high end). Perhaps, playing with various application and document settings will result in the ability for Vision to run on these machines. As at least one of the graphics cards listed appears to share RAM with the CPU, I'd recommend closing out of all applications so that only Vision is running (stop background processes as well if you can). This will free up more memory for the graphics card. It may be possible that upgrading the CPU RAM (and thus the GPU RAM as it is shared) would help alleviate this, but it is too hard to say as CPU RAM will never be as fast and as reliable as dedicated GPU VRAM.
  12. Hmm, interesting! I'm not sure if this would work for you or not... You could create a new layer in Vision, and insert (or drag'n'drop) 4 ARRI 360's into the new layer. You will need to position these so that the light "points" in the proper direction. You could then add a cylinder to the newly created layer from the previous step. If you flag this cylinder as an RGB Mesh, it will "glow" (like a lamp shade), and its color will be based on the DMX values being sent to it. (If you do not need it to be DMX Controllable and simply want it to glow; give the mesh a texture/color and simply check the Force Emissive checkbox.) Note: You may also need to set the cylinder's Cast Shadow flag to Do Not Cast Shadows. This will allow the rest of the document to continue using shadows while allowing light to "pass through" the cylinder. If this works for you, you can select the newly created layer from the steps above and Copy/Paste more "instances" of this custom fixture. Here are some screenshots of an attempt I've made at an RGB controllable "glow" with 4 S4 50degs "inside". I've tried to attach a V3S (no textures, so no folder needed) that you should be able to load to see how I achieved all of this. fixture.v3s EDIT: I may have found a bug related to copy/paste. It may still work for you, it's just that the Scene Graph will not be organized as you might expect. I will investigate this issue and see if I can find a fix.
  13. There's a few things I've noticed when looking at your screenshot above and looking at the file on my machine. 1. The lens and beam of the "red light" isn't red. Only when the light hits a surface does it become red. 2. Textures are not loading in your file where they are loading in mine. I'm not sure why all files on your machine are not rendering properly. What are you system specs? FWIW, here is a large number of screenshots on my machine with various lights turned on/off in the two documents you provided. I tried to show in the following screenshots that both the color of beams and surface lights are rendering properly; and shadows appear to be rendering properly, also.
  14. I'm not sure what would cause this in the most recent builds, but there are a few things we can play with to try to further understand what might be happening. Was this a single V3S file or more than one? Is this issue specific to a single V3S? Did you happen to transfer the textures folder alongside the V3S? Does changing the fixtures Candela / Color Temperature / Color Wheels / Gobos in the Properties Palette effect this at all? What about the Force Emissive flag? This could happen if shadows are off or if the Shadow Quality is set too low. It is recommended to run without shadows while diagnosing issues if at all possible, as shadows put stress on the machine. (Note: To explain a little further, lowering the shadow quality lowers the maximum number of pixels the fixture can "see". Because at very low qualities geometry becomes very pixelated, you might see areas where shadows pass through things they shouldn't and don't pass through things they should.) This sounds like it could also be caused by very low Shadow Quality. It is also possible that this a bug related to rendering updated shadows. When a light pans/tilts, the code must update the shadows map to ensure proper shadows are cast based on the geometry they are pointing at. Assuming shadows are on and that the Shadow Quality is set to, say, Medium; if this is a moving head, does panning/tilting resolve the strange shadow? If this is a conventional, does moving the focus of the light with the arrow keys resolve the strange shadow? We have had reports of this in the past as well. I have had trouble reproducing it in most cases. However, some time ago, I found an issue with how Color Temperature (I believe) was being parsed. I was able to fix "red lights" in this very specific instance in the code. Perhaps, ensure you are on the most recent releases of Vectorworks and Vision just to be safe (and ensure you have that specific fix). Just an FYI: This resolution option in Vision is not necessarily a setting you should match to your monitor. When you do, Vision will attempt to leverage every pixel on the display and this could result in poor performance if many lights are on. This resolution option is intended to give you control over Vision's performance and quality. When you are experiencing issues with Vision, it is generally recommended to use lower resolution values (such as 800x600 or 640x480) as higher resolution values (such as 1920x1080) can put stress on the system. It could be possibly due to file corruption / transfer issues, but I'd expect many more issues than this (in fact, I'd be surprised if it even loaded). Perhaps, you can attach the V3S along with the textures folder in a zip attached to a post here in the forums. This way we would be able to verify if the issue is with the file post-transfer/post-dropbox or not.
  15. Yes. Vision 2021 has moved to OpenGL 4.1 and we weren't able to get the text overlays working properly. We also found some bugs in the reporting, which I believe have been mostly corrected (but since the reporting is no longer public, this information is internal only). We had a very rough POC for putting FPS into the status bar (near the NDI status bar indicator). This is much simpler to achieve than a text overlay in the viewport, but does come with the downside that it is a single FPS counter for the entire program (and not an FPS counter per viewport). There are obvious ways we could remedy this (the most obvious being adding an FPS counter into the statusbar for each visible viewport, with some identifier as to which counter refers to which viewport). It would definitely be interesting to hear from users here on the forums if they preferred the text overlay on the viewport, or if a status bar counter would be sufficient. Alternatively, and the current suggestion/workaround, use a third party application for detecting FPS of Vision.

 

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