Jump to content

CharlesD

Member
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About CharlesD

  • Rank
    Greenhorn

Personal Information

  • Location
    Pennsylvania

Recent Profile Visitors

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

  1. I agree that the Architectural products are better for serious modeling. But I also agree that they are not really practical to the Entertainment workflow. On Entertainment projects I only dip into architectural modeling for a proof of concept. I definitely recognize there's a lot of assumptions being made for the "perfect" calculation. Though in fairness those same assumptions happen in Architectural as well. But for my workflow and the projects I do, getting close is good enough. If I really needed precise calculations I'd be doing it in an architectural program. I think the genius of this though is that VW could be the only program to handle zooming instruments in an intelligent way.
  2. Hey Rob- I think there's to things at play here, and they relate to each other. 1- The modeling of zoom in VW. This is necessarily linear between the min and max, and I imagine pretty straight forward from a programming perspective? 2- After we get the zoom sorted in VW. We can improve the photometric functionality. Regarding how zoom relates to candela, this is understood: We don't need more than two data points to get a useful approximation. Using min and max beam angle/candela values we can created a weighted average for any discrete beam angle in the range. With the generous support of a friend, here is a screenshot from an excel spreadsheet that is the exact formulas I'm asking VW to have. This spreadsheet takes the min/max data point, you enter a discrete angle along that range, and it creates a weighted average. If this could be fed into the Candlepower field in VW it would make this all work. (This screenshot example is also for the VL-3500 spot.)
  3. Thanks Rob. I think it needs to be more in depth than just a min / max toggle. If we could have a slider that could adjust between the min/max values that would be super ideal! That would really make this tool functional.
  4. Rob, let me try re-explaining this way: Here is the VW built in VL-3500 Spot symbol. Note the following values: Beam Angle - 10deg Field Angle - 60deg Candlepower - 1201000 This is not correct. According to the manufacturer, this should be: Beam Angle - 9deg Field Angle - 10deg Candlepower - 120100 What that means for me. Currently it is impossible in Vectorworks for me to layout lights and see both their coverage, and the amount of light they create, in any reasonable fashion. Because this is a zoomable fixture, that is to say the angle of the beam of light is variable, the beam angle would more accurately be described as "9deg to 46deg". Vectorworks has no provision to deal with variable zoom lights. As a work around, for zoomable lights everyone puts the narrowest zoom as the beam angle, and the widest zoom as the field angle. That is why the built in VL-3500 Spot symbol is made the way it is. This allows you at least see the range of coverage you can get out of your light. Take a look at the attached Screenshot 1. While doing this work around solves one problem, it creates another. It obliterates the usefulness of VW's photometric tools. Specifically, "Photometer" and "Photometric Grid". Take a look at the Screenshot 1 again. See that my Photometer is telling me I should be receiving 34 FC of illumination at that point. (As an aside: Obviously the Photometer tools make a lot of assumptions: no color, no shutters, no gobos, etc. But at least it gets me in the ballpark.) Because the fixture is using the candlepower value of the light at its narrowest zoom and applying that to the area of widest zoom, this screenshot shows data that is entirely wrong. As far as I know, Candlepower value cannot be changed on a per fixture basis. That means anyone wanting to use Spotlight for estimating light levels for a zoomable fixture is totally up the creek. Because the angle of light and its candlepower are correlated, and you cannot adjust the candlepower of a spotlight fixture, that means if I want to create photometric evaluations of zoomable fixtures then I would need to have a discrete VW symbol for every beam angle. My library would look like this: VL 3500 Spot - 9deg VL 3500 Spot - 10deg VL 3500 Spot - 11deg VL 3500 Spot - 12deg VL 3500 Spot - 13deg VL 3500 Spot - 14deg ...etc... VL 3500 Spot - 46deg Let me know if that phrasing makes more sense?
  5. Thanks Rob. Now I see what you are saying. We are talking about two different things. I do not want to make any changes over time, or in anyway previz. I am not asking for anything like what I would want out of Vision. I'll post again when I can figure out a way to better phrase what I am trying to say.
  6. Thanks Rob. I don't totally understand what you are saying. What do you mean when you say lights are "static"?
  7. Hey Rick. Thanks for these notes. I think that the zoom functionality is something that's missing, and important though. And what I'm suggesting with Candela is basically you provide the candela at the narrowest field of view as well as the beam/field angle at narrow field of view and the candela at the widest field of view as well as the beam/field angle. While it's not scientific, I think assuming a direct relationship between zoom range and candela min/max would at least get you within an order of magnitude for your candela value along the zoom range. See the image in my first post. Basically I would input the NFOV and WFOV values into a fixture. This could be very helpful for me. A very common task for me is this: I have a fixed lighting position, I need to decide the quantity of lights to array on that position and how to focus them to achieve an average light level of X. Right now Vectorworks doesn't allow me the tools to do that. As discussed, I can fake my zoom range using beam/field angles. But then I lose relationship to light output. It seems like zooming lights have been around for too long for VW to not have addressed this core functionality in the way it treats lights.
  8. RE: Fixture Mode Good to know that's a vision thing. I could see it being helpful as a data field in general though. I've noticed a few issues with the fixture modes menu though. Like multiple fixture modes with the same name. It's not possible to tell the difference between five identical items.
  9. I couldn't seem to find documentation for the changes to the default Light Info Record in 2017. Off the bat I've noticed: Time Cost Fixture Mode Are there any others I'm missing? I'm also curious for everyone's thoughts on how to use Time / Cost / Fixture Mode. Time What is time? Is this for installation labor estimates? Or is this like Lamp Hours? Or what? Cost Are you guys doing street value to purchase? Rental cost per day? Per week? It all seems so variable... what's the point?
  10. As far as I understand, photometrics are handled terribly in VW for lights that zoom. Please tell me if I'm missing something here. A light is able to have a beam angle and a field angle. (It can also have both in a perpendicular axis, i.e. for PARs) There is nothing in a light that references zoom range, so what I'm seeing most people do is put the Narrow Zoom Beam Angle in for "Beam Angle" and the Wide Zoom Field Angle in for "Field Angle". Is this the best approach? Or should it be Narrow Zoom Field Angle for "Beam Angle"? How does Candela respond to zoom range? As I understand it candela is a unit correlated to beam angle of the output. So what Candela value am I supposed to put into the symbol of a light that zooms? Let's say I put the narrow zoom candela value in... then if I go to do photometric layouts it is going to be all wonky. It seems like the answer is LIR needs Beam1 / Beam 2 / Field 1 / Field 2 / Candela -- NARROW as well as Beam 1 / Beam 2 / Field 1 / Field 2 / Candela -- WIDE. Then it needs a zoom slider thingy that adjusts those values in a proportionate relationship. No?
  11. I have a DLVP referencing in another department's file that includes a section view and additional geometry drawn in plan. I'm attempting to rotate my DLVP in 3D to put the section view as a 2D background for my own 3D geometry. When I try to rotate the DLVP in 3D it says "hybrid objections can only be rotated around Z axis". When I turn off all but one layer in the DLVP I can then rotate in 3D. Turning on the other layers appropriately puts the geometry into the correct place. However, Sheet Layer Viewports looking at the DLVP see the DLVP has in plan, not in side view. Saving and re-opening the file returns my DLVP that was in 3D into a plan orientation. What gives? Anyone experience this odd behavior before?
  12. So I'm trying to create a script for myself to prep newly acquired symbols to my drafting standards. I've hit a couple of stumbling blocks with the script I've cobbled together from examples on this forum. 1. I want the script act only on selected symbols. Currently it acts on any symbol in the file. 2. I want to build all of my prep steps as separate functions. And then call them in the main procedure individually, so I can tweak and build on this script easily as future needs demand. 3. My object attributes thing works okay, but the intention is to only set the fill color by class IF the color is white. If the color is anything but white, I want the discrete color to remain. I suspect currently my script isn't evaluating each object within the symbol, as it should be. 4. My Locus function isn't working as intended. I want to first open the selected symbol and delete any instance of a locus. Then I want to insert a new locus at 0,0 on class "Symbol-Locus" inside the geometry of the symbol. Currently it just puts it in the drawing at origin. Any help here would be greatly appreciated! Thank you! PROCEDURE LightSymbolMaintenance; CONST X0 = 0; Y0 = 0; VAR I :Integer; ClassName :String; r,g,b :Longint; function AttByClass(H :Handle) :Boolean; { Set all object attributes by class, unless the fill color is not white. } Begin SetPenColorByClass(H); SetOpacityByClass(H); SetLSByClass(H); SetLWByClass(H); SetOpacityByClass(H); SetTextStyleByClass(H); SetFPatByClass(H); GetFillBack(H,r,g,b); Message(r,g,b); {Test to see what color this thing is seeing} if (r <> 255) & (g <> 255) & (b <> 255) then begin SetFillColorByClass(H); end; End; { SetAttByClass } function InsertLocus(H :Handle) :Boolean; {Delete any existing locus, insert a new locus on layer "Locus" at origin} Begin Locus(X0,Y0); End; BEGIN { Change all objects in Symbol Defs to accept colour attributes "By Class" } ForEachObjectInList(AttByClass, 0, 2, FSymDef); ForEachObjectInList(InsertLocus, 0, 2, FSymDef); SysBeep; { sound off when done } END; Run(LightSymbolMaintenance);
  13. Hi Andrew I see what you are saying... Interesting concept that solves another issue that I haven't even gotten to you. Thank you for sharing. I think my issue is different: If you check my upload photo sequence you will see that when I rotate my 3D geometry my 2D geometry rotates as well such that what was the outline of leko now becomes a single line. I would have assumed that setting the 3D orientation of a hybrid object would affect 3D geometry only. What I am seeing is that 2D geometry is also rotated. Does that make sense? Cheers.

 

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