Jump to content

scottmoore

Member
  • Content Count

    428
  • Joined

  • Last visited

Community Reputation

235 Spectacular

4 Followers

About scottmoore

  • Rank
    Journeyman

Personal Information

  • Homepage
    www.goliveproductions.com
  • Location
    Nashville, TN

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. It appears that the issue has been corrected in SP2 on both my desktop and laptop. I appreciate your hard work VW engineers!
  2. The problem seems to have been rectified in SP2. Thank you VW engineers!
  3. Indeed. That showed up when I upgraded to SP2 which means now I have additionally functionality that I do not want nor have any need for that will do nothing but slow down my drawings. Thanks for the info though Mark!
  4. Updating to SP2 seemed to fix the issue. Now I have a loci in the middle of each symbol after I have used the numbering tool. Odd, but certainly not as big a deal as what I had earlier.
  5. I've created a series of symbols used to identify cables for a specific use. Each cable has a label legend that identifies the DMX address and User #1 which, in this case, is the output to which the cable is patched. The color of the symbol denotes length. The information assigned to the cables is that they have a DMX footprint of "0" so that I can utilize the actual DMX footprint of the fixtures being used. For this instance, every cable has an offset of 6 for the DMX address and 1 for outputs so that cables should be output #1, DMX address 1, Output #2, DMX address 7, and so on. This all works great. I have the numbering set up to restart at 512 and that works as expected as well. The issue is that, for some reason, the auto numbering scheme cannot enter the numbers 49 or 55 in DMX address fields. See the attached image. As you can see, it picks right back up at 61 and then continues on as one would expect. When selecting those "fixtures" the data next to the cursor indicates 49 and 55, but that is not the data that is entered. Once entered, the OIP denotes 1 and 7 for those two symbols. If I start the numbering tool at 49, the first two symbols are numbers 1 and 7 and then it continues on to 61. The ONLY way I can get a 49 or a 55 is to directly enter the data in the OIP. As you can see, this is not a recurring issue every 48 channels as the subsequent symbols all behave as expected. I have run this with all iterations of this symbols package and have gone far enough up the address chain to get the units to reset after reaching 512 channels. I have also restarted VW. I am on VW2020 build 508509. Any ideas where to look for the issue?
  6. “BraceWorks....” (say it just like Seinfeld said “Newman”)
  7. That sounds far more reasonable. Thanks Mark.
  8. I agree. I’ve always been a proponent of creating three symbols per symbol type (hanging, floor and yoke out) to avoid the 3D rotation and the various issues that can cause. It also completely solves the challenge you are describing.
  9. This does not work in 2020. It works in OpenGL but not at all in renderworks.
  10. Just a note to everyone that has purchased the backline symbols package: first of all, thank you. Secondly, there is a bug with VW2020 as it relates to image textures that can be colorized by the object to which they are applied. In a word, that functionality does not work. As such there are some issues with the symbol package. - drum kit finishes are not correct and can not be colorized per the instructions. - the same is true for grand pianos. - some percussion instruments will look a bit odd. I am hoping that VW will sort this out soon as it not only impacts the symbol package but also deeply impacts a lot of my rendering workflow. If anyone has any issues, I can create some temporary textures for you. thanks, Scott
  11. I would agree. You can make your facility render as simple or as complicated as you like. Use textures in place of some of the complicated geometry to keep render times down.
  12. I’ve been posting about renderworks “caching” for several years now. It’s never been a reproducible problem that I am aware of, but simply shows up from time to time. The symptoms are updating geometry that works just fine in wireframe and OpenGL but reverts to a previous iteration in Renderworks. The solution is to restart. While I can’t say the problem has been rectified in 2020, I can say, I’ve not seen it since upgrading.
  13. Neither restarting the application or the computer solved the issue. - create new “Renderworks” texture - under “color” select “image” - select an image file - select “use object fill” under the “filter color” option - set texture size as necessary. render in OpenGL? Just fine render in Renderworks? Nope very frustrating as I’ve created a ton of symbols with this very useful functionality which are now (pun intended) rendered useless.
  14. I am finding an issue, at least on my MBP involving textures created using an image and having the color filter set to object fill. When using that particular parameter, textures render correctly in OpenGL but turn black in Renderworks. If I disable the filter by object fill parameter, the textures work just fine. To test I just tried this with a blank document, one piece of geometry and one texture.

 

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