Jump to content

Hello Community!

This Thursday, October 21st, from 6 pm to 7 pm EDT, we will be performing an update on the Vectorworks Community Board. During this time, the site will be unavailable.


  • Posts

  • Joined

  • Last visited

Everything posted by scottmoore

  1. This tends to come up randomly in most of my drawings on both my laptop and desktop. Next time I find one that has a consistent issue I’ll forward it on. For me, it’s just that textures disappear when using RenderWorks. On my design process I keep both custom RW and Final Quality RW (I know....) on hot keys to quickly render and see what textures or geometry appear. It seems that once a texture disappears (and I believe it is always an image texture) that it then continually has an issue. I’ve investigated the file sizes of the images in question and that does not seem to be it.
  2. Steve, we’re you rendering on the design layer by chance?
  3. 125% is generally my default. My opinion is that most LED displays will emit more light than that even when the NIT level is dialed back. I often help things out a bit by adding an “ambient” light or two to a render.
  4. No. As you can see, at 250% the image gets quite blown out. I generally find that I can’t go much over 125%-135% before the image becomes unusable. Of course, that also depends on the image.
  5. A few examples depicting light emitting displays. The room in which this display is placed is 100' x 100' x100' and just uses white as a finish. Another note is that the screen tool applies the texture to BOTH SIDES of the face so if you want to block the back side from being visible or emitting light you need to make the base structure the same size as the modules. Likewise, in the example where I included simple geometry to create a screen, you would also need a blackout piece of geometry in the back. In this case, it would also NOT cast shadows.
  6. Also note, if you want to actually see the glow you will need to a) enable indirect lighting, which incidentally is true of any glow texture that emits light, and b) you will need at least one other light source in the drawing so that you can turn the VWX ambient light off. For instance, if you just want an LED wall to illuminate your scene, you will need to turn off ambient light and place a light object with an intensity of 1% and possibly even give it a dark gray color. The light object will effectively be “off” but VWX won’t know that. If you have no legitimate light object in the scene, VWX will turn on the ambient light by default.
  7. I tried it. Didn’t work. Since the glow texture emitting light is not actually a light source that VWX recognizes, it does not penetrate through a piece of geometry that includes a texture that does not cast or receive shadows. Kind of a drag as that would have been a useful tidbit. You can certainly put a light object behind that texture but getting the shape of the light source correct would be a nightmare.
  8. Which brings up another question: how is that output actually calculated? I tend to find that I cannot get enough light out of a display to render realistically before the image blows out. As I am writing this it occurs to me that perhaps I should let the image blow out quite a bit. What I will try is duplicating the texture with one completely blown out and the second at a normal intensity, however, set the second not to create shadows. Then I place the blown out image on my screen PIO, create a simple piece of geometry in front of the screen and map the second texture there. That should give you the best of both worlds. I’ll give it a shot when I have a minute.
  9. Matt, thank you for that insight. That might then get us back to the RW camera dpi setting vs the sheet layer dpi setting vs the rendered output dpi setting conversation. 🙂 It still baffles me a bit but I just stick with the sheet layer dpi. Regardless, being able to accurately render on the design layer should be a standard part of the design process. Anything else, including render bitmaps (terrible) is a massive distraction from the process itself.
  10. Perhaps to clarify why I think this is important: if I am developing a new texture (that may include reflectivity, bump shaders, transparencies, or luminosity, NONE of which can be seen in OpenGL) I want to look at that texture in use immediately so I can make changes as needed. Often it requires several passes to get a texture the way I want it. To do so, I center up the item on my monitor and use a keyboard shortcut to render. The rendering starts from the center out. Often times it only takes a few seconds to see what I need to see and then I just go back to wireframe and adjust as needed. Likewise, the same process is used for investigating lighting, gobo textures, shutter cuts and any number of items that require a quick reference so as not to have to waste time later. This should be easily accomplished directly on the design layer. I have generally found that design layer renders (which I believe are 72dpi) look pretty great. Sheet layer viewports of similar quality typically require 150dpi or higher to look comparable and take longer because of it. I don’t really understand why that is. For what it is worth, I used to do all my output rendering from screenshots of the design layer before I figured out sheet layers. There was never a problem until fairly recently.
  11. This has been going on for quite some time. There are plenty of comments about this. Perhaps search “render cache”. I will say that I’ve not seen it nearly as much in the past year or so. Actually, I am not sure when the last time I saw it might have been. I am on 2021.
  12. Ok so 2 1/2 years late and this would still be a workaround, but what if each of your 14 symbols became lighting devices and the texture that needed changing received its color by object and the particular geometry to which this texture was applied received its color by class and you made that class a “lens” class? Then all you have to do is assign a color to the “lighting device” and it would change the texture color of each individual item. Don’t forget to set your Spotlight preferences to allow fo this.
  13. While this doesn’t really help you, I’ve always been a MBP user and have never run into this issue. I do a ton of rendering in VWX. So long as my laptops have been on a power adaptor, I’ve never even considered battery life. That seems really odd.
  14. Works great as export PDF with layers. Just did a test file.
  15. Ok, so first thing is I wasn’t aware you could export PDF with layers. Seems like this will work like a champ. Stand by...
  16. Sean, I am bringing this topic back up as I just bought a Glowforge Pro and am interested in your process. When exporting a PDF, should I assume that line/fill colors can be used as scoring, engraving and cutting? Some experimentation today is in order I think.
  17. I would tend to disagree with this. It is crucial to be able to have the potential to cast shadows or not per texture. If you place a light object inside a piece of geometry, the texture applied to that geometry needs to not cast shadows in order for your light to work. Not casting shadows is often helpful when using process renders when you want to investigate how things look without waiting for shadows to render.
  18. I was a late adopter of that button as well, but certainly speeded up the process once I realized it was there! The thing about a CAD program like VWX is that accuracy is really important. That is why there is less interactive than you might suspect. Sometimes that can be a downfall when you “just want to make that tree a little bigger”.
  19. Not exactly what you are looking for but “scale by distance” might help you. I find it to be rather quick.
  20. True, but it is far more time consuming than simply rendering on the design layer. I’ll give that a shot.
  21. For what it is worth, I have had this issue in both 2020 and 2021 on multiple files with three different machines; two laptops and a desktop. I just find it incredibly infuriating.
  22. Depending on your requirements, you could also consider image props.
  23. That does seem odd. I don't recall ever having that issue. It sounds like a bug. Are you on 2021? In 2021 I just tried a referenced file via viewport (which is how I always do references so that might be an issue). I tried renaming a class in the reference file to the name of a class I had in the primary file. Made sure to save the reference file but left the file open. I updated the reference and it worked as expected. I then changed the name of another class in the ref file, saved it and closed it. Updated the ref in the primary and it still worked as expected. Might be worth a call to Service Select if you have that service.
  24. First of all, this sounds like an awful lot of work maintaining multiple files when you do not need to do so. That said, I also understand the need to move forward on existing projects in their current configuration, but definitely look into the section view functionality in VWX. It's not difficult and that will be a huge boost to your productivity. In the navigation palette, select the references icon at the top (should be the last w=one on the right). When you select that, every file you have referenced in should be visible. If there have been changes made tot he reference file, the name will appear in red text. Off the top of my head, you right click on the referenced file to brig up a window that will allow you to update. I believe there is also an option to auto-update those files. Does this help?
  • Create New...