bbudzon

Vectorworks, Inc Employee
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

4 Neutral

About bbudzon

  • Rank
    Greenhorn

Recent Profile Visitors

195 profile views
  1. We definitely need to get a better way to find Vision fixtures in VW. A little developer secret, in 2017 the Inst Type can _sort of_ be used as a search box for populating the fixture mode. In 2018 Beta, this was moved to the Fixture ID field.
  2. I may be able to clarify some things, if there is any misunderstanding. Universe and Address are fields that, in both VW and Vision, contain plain data. Basically, it is just a number. It was not hard to get both VW and Vision using these numbers, and that is why when you fill out Universe/Address information in VW it exports to Vision as you'd expect (btw, if you want to change what fields in VW map to Vision you can do so in the Spotlight Preferences->Vision Mapping). Gobos and Colors were not so straight forward. While we do want to work toward having one mechanism for Gobos and Colors, we haven't had the opportunity yet. It will take some time for us to get Vision switched over to VW resources. That being said, we have two "sets" of Gobos/Colors resources in VW now that Vision has been integrated. One set is specific to Renderworks; this is what you are likely used to using. But there is also a new set of resources that are specific to Vision. The gobos/colors you have likely always used only effect Renderworks and are specific to VW, meaning they are selected through VW resources. The new "set" of resources/fields/dialogs is the Vision set. If you are running VW 2017 or newer, you can either continue using the old "Edit Vision Data" dialog to set Gobos and Colors in VW and have them export to Vision (although these will not effect Renderworks because they are Vision specific). This is the old workflow that Vision supported back in the Vision2/4 days. Alternatively, we have added a "Color Wheel", "Gobo Wheel", and "Animation Wheel" to the Lighting Devices OIP Edit button. Someone else may need to chime in here, but I believe once you have your fixtures set up in VW with Vision Data and Renderworks Data the way you'd like, you should be able to copy and paste that fixture into new VW documents. Hopefully that will save you the time of having to "redo" all of the same gobos/colors over and over again. The last thing I will say is that any time you can set something for Vision from VW, you should. The reason being is that the communication between the two products is currently one way. This means that the vwx will always be the "master" file. If you keep it up to date, you should be able to get _fairly_ close to the same esc/v3s by exporting it again. Some things, like conventional pan/tilt, will need to be adjusted every time you export from 2017, and that is something we are looking into.
  3. Just wanted to clarify something Eddy, we changed that grouping behavior. We couldn't come up with a good reason not to export groups, so we changed it to only export items that are marked as Visible in VW. That being said, groups are now exportable which is nice from a VW standpoint, since some people may be prone to group all of the stage geometry together (or perhaps mic geometry and the podium).
  4. Unfortunately, I do not believe it is possible to update Vision content in VWSpotlight without using the Vision Updater while a dongle is plugged in. Reason being is that the content updates are paid for and we need a way to verify that the person asking for the update has paid. Luckily, Vision does have a dongle system. This allows you to install Vision onto as many machines as you like because, unless the dongle is plugged in, it will not update and will only run in demo mode. My recommendation then for your work would be to install Vision on all of your VW machines and "share" the dongle to get content updates into VW. Again, the main advantage of a dongle is that only one non-demo copy of Vision can be running at any given time. So, we don't have to worry as much about pirating because you own a more "physical" license to our software. Product keys are obviously a different story because they are essentially virtual dongles. Being virtual, simply using one product key on two systems “duplicates” the license and, if we didn’t check for it, would allow you to run two copies with one key. With the dongle (physical license), we don’t mind giving you Vision content for all of your VW machines since the content is useless outside of Vision. One dongle still allows you to only run one copy of Vision, which is our main concern in licensing. Lastly, we do realize this can be improved and we are looking into ways in which we can streamline this process in the future. Hopefully this helps!
  5. This would work _most_ of the time. We will have to tweak your seating section a little to meet the requirements of the point I'm trying to make, but it will show you potential problems in only checking the last seat. Imagine a circle going through your last row. Now imagine that that circle _almost_ touches the edge of the bounding box but doesn't actually touch it. What we end up with is essentially one arc segment instead of two. Now whether we check the center point of the seat or all four corners, if we only checked the last one/two seats of that segment, you'd get those middle seats of the back row strutting out of your seating section and then you guys would wonder (as would I if I were you) why we aren't obeying the boundary. One potentially solution involves special casing arcs that are close to an edge so this doesn't happen, but this gets terribly complicated when you introduce holes/convex hulls (think donuts and U shapes, better yet think Swiss Chese lol). There is definitely room for optimization of the checks for inside the boundary, but there are a lot of weird edge/corner cases that force us into choosing a fork in the road. Some people will be happy those seats are strutting out of the seating section because they didn't want two back rows. Others would be happy that it split the back row, because there truly isn't room for those seats on that particular arc (you can always custom place seats by clicking "Edit Seating"). I'm hoping that as we continue working on this and getting feedback from you guys, we will be able to improve the workflow to support all of the cases you guys need, hopefully mitigating some of those "damned if you do damned if you don't" type of bugs. You could absolutely curve that edge so your seats would fit. I would think this would be one of the better solutions. Perhaps the main point I wanted to make, however, was that you can control "orphaned" seats to some extent by using the "Minimum Number of Seats Per Row" limit value. In your example above, you could set minimum seats per row to 6 and the back row (which is probably actually two row segments) should be removed. Unfortunately, this variable is global to all row segments (in curved seating) and it would also remove the first row in your example (all rows with 5 seats or less will not be placed). This was mainly introduced for curved seating as a perfect square with a focus point in the center often ends up with 2 seats in every corner (or something like that). Unfortunately for me, I don't pay much attention to who this tool is for (ok, that's not entirely true!). So, I apologize if accounting for 1000's of seats in a seating section is kind of silly. Figuring out what you guys need is more BrandonSPP's job I get to argue with Brandon about how every possible feature that can be implemented should be supported and he scales me back hahahahh So when I started on all of this I wanted to support S-shaped Swiss-Cheese-Holed Curved seating sections that have been chevroned 15deg and rotated in world view 90deg and are large enough to cover a WalMart parking lot Oh and don't forget alternating row offsets! I want it to do it all, and all at once! But in all seriousness, that's where your guys' feedback comes into play too. If you guys aren't making seating sections that big, we can do things like beef up the algorithms so they are smarter, albeit a little slower.
  6. We definitely appreciate the feedback. Just a few thoughts: 1. Curved seating should respect the boundary and this is something we are looking into. In the original implementation, we were worried that performing 4 checks on every seat would be too slow. Especially in very large seating sections that may contain 1000's of seats. Our solution to this was to use the center point of the seat instead, limiting the number of checks per seat to one. Unfortunately, while the center of the seats were guaranteed to be inside the bounding box, the legs of the chairs were not. We had considered putting in a default offset, but I'm not sure this made it into the release. Possibly the most important part of this point is that this bounding box offset can be controlled through the "Allowable Distance Past Boundary" field (which can be positive to push seats out, or negative to pull seats in). Try tweaking this value to get seats closer to/further from the edges of your seating section. Not ideal, but hopefully it will provide you guys with a workaround. We are investigating what would be required to remove this offset entirely and perform a real check on all four corners of the chair, but it may slow the tool down significantly (which I guess is better than never getting the seating section you want!). 2. "Seat Spacing" for curved seating, specifically, is a minimum spacing value, not an absolute value. In our original implementation, the spacing for curved seating was absolute. However, this caused the seating section to not align along the edges. This is mathematically impossible. If all seats are along an arc and they must be spaced exactly the same distance apart, you cannot guarantee they will align on an edge. To make matters worse, because each arc has a different radius, each row will align to each edge differently. This made it almost impossible to get a "pretty" seating section. So basically, in order to make the seating section look symmetrical, we HAD to treat this as a minimum value and not an absolute value. We could look into adding absolute value spacing to the curved seating, but if you guys saw what we did during development, you'd never want to use it It was pretty ugly... Much prettier when it aligns along those edges for you. 3. The reason the last row shows a gap in the middle is because of the check that occurs when placing a seat. In the current implementation, if the center of the seat is not in the bounding box, it simply isn't placed. In this case, almost all of the seats in the last row fit inside the bounding box, but the few in the middle didn't. There are two ways to address this. The most obvious solution is to reshape your bounding box, dragging the left edge a few inches, so these seats can now pass the check and fit inside the poly. The other option is to use the "Allowable Distance Past Boundary" that I specified above. The downside to this method is that it applies to all edges. The reshape will only add more seats on the edge you extended. 4. This is definitely appears to be a bug. We will look into getting a fix together to address the issue.
  7. When you click on the Fixture Mode drop down and select "Other...", is the dialog populated with Vision Fixtures? If so, are you just not seeing the Ayrton Versapix-RS? Also, if you could, is it possible for you to get us screenshots of this fixture missing from the VW "Other..." dialog as well as a screenshot of it being properly listed in the Vision application? This may be a bug, I'm just trying to track things down to figure out if we should open a JIRA ticket or not. We may want to do this regardless just for tracking purposes. Lastly, is it possible for you to attach all of the files the Vision Team gave you?