scottmoore

These tools are indispensable.

“Master Snap”? I learned something new! Thanks J!

The simplest solution here is to create a polygon and map your images to it. Ideally you would make sure all your content (textures) are the same size so when you map the initial image to your surface you can then simply replace the image. If you need to show various images in your renderings, then simply duplicate this surface multiple times and place each iteration on its own class. Then you can change images simply by toggling classes in various renders. Of course, you can also have the displays default to the class texture and swap images in the Nav palette. While having some additional functionality in the LED tool would be great, drawing polygons is pretty simple and easy enough to manipulate.

I would assume that once you rotate the arc, VW is abandoning the 2D geometry in favor of 3D geometry by default. If that is the case, I would suggest creating a hybrid symbol.

Perhaps it is just me, however, from a design mindset, it is important to get ideas out of one’s head and into the computer as quickly and accurately as possible. It seems like the initial design process has become overly complicated in service of simplifying the details required after a design has been approved. I find it frustrating and typically just avoid it altogether.

Possibly check your VW system preferences? I am not at a computer currently but you can define the level of detail. Also, assuming you are using the sweep function, make sure you have your segment set low enough.

It appears that the issue has been corrected in SP2 on both my desktop and laptop. I appreciate your hard work VW engineers!

The problem seems to have been rectified in SP2. Thank you VW engineers!

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!

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.

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?

“BraceWorks....” (say it just like Seinfeld said “Newman”)

That sounds far more reasonable. Thanks Mark.

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.

This does not work in 2020. It works in OpenGL but not at all in renderworks.

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

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.

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.

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.

I’ll try that.

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.

One example of this being a very good thing would be adjusting the zoom of a specific fixture, assuming the fixture includes zoom capabilities.

when creating symbols, you could set one each of the BEAM and FIELD fields to their min and max settings so you can see your range at a glance. That would mean you would have to adjust a fixture to use it properly but you probably have to do that anyway. Just a thought.

Make sure you have SYMBOLS, PLUG In OBJECTS selected in your resource palette. There should be a hierarchy of folders in which the symbols are stored. Let me know if that doesn’t work for you.

it depends on how accurate your Photometrics need to be. That data is typically available from the manufacturer. If you are rendering, then it is more of a question as to how sharp your edges are. Play around with it for a moment and you will figure it out. Generally you want both BEAM fields to have the same value and both FIELD fields to have the same value. There are two fields each to accommodate non-axial mounted PAR lamps that project an oval beam. Now that those lamps are no longer manufactured, it will eventually become a moot point.