Jump to content

P Retondo

Member
  • Posts

    1,828
  • Joined

  • Last visited

Everything posted by P Retondo

  1. @Tony Kostreski Thanks for the suggestion, Tony, but absolutely no joy. 2 comments: 1) when I enable layer colors in preferences, my design layer went all black & white (no, I do not have "Black & white only" checked). That alone is unworkable, because I do want to display different line colors and fills for different objects. With "use layer colors" checked, the color preferences are applied universally to every object, erasing all carefully-intended differentiation. And 2) my viewport on the sheet layer was unchanged! Trying to override layer color selections in the sheet layer viewport resulted in zero change. This is the exact opposite of how things should work. I should see all my selected colors in the design layer viewport, and be able to see things differently in the sheet layer viewport of the same objects. The only way I can get layer colors to display in a sheet layer viewport is to create a design layer viewport to duplicate the original layer, override the layer colors in that, and on the sheet layer viewport check "layer overrides" when editing layer properties. In sum, this obviously won't work for the desired purpose, which is: to have a design layer that shows a building plan as we would like it displayed for a plan viewport, and to use the same layer or layers grayed out as background for MEP or structural drawings. However, if we could enable colors for a Sheet Layer Viewport (only!!), and have it actually work for that viewport (per above, sheet layer viewport layer colorss do not override), we could get exactly where I want to be (image generated by the means described above in paragraph 2): Again, the problem is that in order to get this I have to check "Use layer colors" in document preferences, which overrides all of my fills universally. Unless you have a way around this. If not, it seems like the basic capabilities are there. All we need is to be able to override layer colors in an INDIVIDUAL SHEET LAYER VIEWPORT, without having that affect every object in the file.
  2. Gray background layers in Sheet layer viewports show the 3d content. That's not what we want! What we want is a grayed version of the background layer. How it is now: How we'd like it to be: See the difference? Some folks would also like to turn off all fills in the background, which would be even better.
  3. @willofmaine Yep, except for the fact that mapping to various PIO fields is starting to fail, InfoEditor is faster. I copy my old InfoEditor files to the PIO folder. I agree with all your points. And I've done this for your particular situation: instead of having both layers in the same viewport, have 2 viewports superimposed and turn off the ID tag class for the background. My longstanding suggestion for the stairs PIO - because we usually do this anyway - is let us generate a stairs from a set of 2d polygons as the parameter input. Posts crossing over: I just use the door or window opening option because it's convenient and parametric. No particularly compelling reason. On unique data derived from a PIO instance wrapped in a symbol, I can see the complexity of getting the code right, but it would be fantastic.
  4. @Pat Stanford I think that's a great overview, Pat. There used to be a third party utility called "Info Editor", which I have used for years and still use, even though some of the code is now out of date. It allows me to make global changes in PIOs and to almost any object (of a legacy type now) that contains data fields. Vectorworks really needs to bring that in as a tool, and update it so that parametric objects can be edited with a power similar to the use of symbols. The fact that symbols can contain record links that allow individual instances to be uniquely edited is another crossover feature. Seems like the ID tag and similar sorts of data features could be treated the same way with limited modification of the code, like you are suggesting.
  5. I always thought the main difference between a symbol and a PIO, besides that a symbol allows multiple instances to be edited at once as Pat says, is that a PIO is a parametric object - one that will automatically generate geometry based on user input. Different animals, it seems to me. And from my point of view, the greatest weakness is that the door and window PIOs, among others, do not actually do what designers want them to do and have longstanding faults that have never been fixed. I wonder, Will, what exactly are you trying to do with the Data Tag idea?
  6. @Pat Stanford My question was directed at both parties, and your answer conforms to my experience. But I took from the original post that isyme's office experienced automatic re-rendering of sheet layer viewports that was slowing down their work. I wondered why that was happening given the two modes of program behavior you describe, and maybe it has something to do with teamwork. He/she refers to "exporting" in the course of their work.
  7. To clarify, and rereading your post maybe your practice differs from mine - I frequently use a door PIO in "Opening" mode, which creates the opening in a wall, and place a coincident symbol composed of 3d objects in it. I've never used the opening PIO to convey data, but I suppose it could, depending on what you want to do.
  8. I don't know, maybe that's the case if you are using a single PIO instance to create multiple symbol instances. Pat? Have you thought about using the user-defined fields in the PIOs you use to create your openings? In the end, the best solution would be to have better PIOs so we don't have to resort to a workaround!
  9. Will, I take it that the user-defined data fields in window and door symbols do not do the job for you?
  10. Pat's suggestion is a good one, and I typically operate with "Save Viewport Cache." But I'm a bit confused, and maybe Pat could clarify - without "Save Viewport Cache" my sheets open with a wireframe unrendered model. I take it that for some reason yours do not?
  11. @rDesign Absolutely, the blocking of panning and zooming is a huge problem.
  12. @Matt Panzer Matt, I love this conversation - is any of this going to be part of 2021? I'm looking for a reason to drop another chunk of cash on VW this fall, and so far nothing.
  13. If there were a way to uniquely identify the 6 sides of a rectangular prism! I could see the code for this becoming too complex. Besides that, simplification is going to be necessary. There is no way to accurately model the complex section of an extruded / pultruded window frame, or cladding over wood vs. painted, etc. Something I've always wanted: the ability to correctly model the section of a door or window sill. As you are no doubt aware, the current PIO is (forgive me) abysmal, and the results superimpose a sill over a non-existent bottom frame for windows. If the sill were an extrude, I could ungroup and put my own 2d polygon in. Better yet, if the PIO would accept that polygon and still remain a PIO!
  14. @Matt Panzer Matt, let's not get hung up about mitered frames! They are almost non-existent in cabinets, doors and windows. Correction, they are non-existent 😊. I'd like to apply a different texture to different faces of an extrude, sure, but I would settle for the way things are and use zoomer's workaround. Are we letting the perfect become enemy of the good? What I'm thinking is that if (big if) there is an effort to rework these fundamental PIOs, it would be helpful to do them in a way that makes them more useful.
  15. @FBernardo FB, I described my method in this thread: Matt, I wonder why the interest in applying different textures on the same 3d object? That does not track with physical reality. I would look more in the direction of finessing the extrude to do what you want. For example, it is possible to model a simple frame with 5 extrudes to achieve the results we want. That first image is OpenGL, with lines only at the boundary of the frame, while the wood texture is applied to 4 extrudes with lineweight = 0. The second image is the same set of extrudes in hidden line view.
  16. Good point, Matt. This is an issue we deal with in drafting all the time. A solution would be awesome!
  17. Matt, the only object I can think of in these tools that cannot be built from extrudes are the stringers and railings of a circular stairs. I would construct those virtually from an extrude-along-path, which could again be something the user could modify. I think too much is being made of the complexity. Think of it this way: how are these things actually built? In the vast majority of cases, they are constructed of linear materials with profiles that can be defined by a 2d object. They should be modeled in the same fashion. Then when you want to apply a wood grain texture to a window sash, for example, it would look like an object in the real world instead of an embarrassing kludge.
  18. @Matt Panzer I understand, but at the same time I would like to observe that 1) I often create custom stairs completely out of extrudes, it takes very little time, and could be easily automated from parameters and, 2), the solid objects from which windows and doors are constructed, though not meshes, are not easily modified if the objects are ungrouped. I am specifically advocating for extrudes only, because only they have accessible 2d primitives that can easily be manipulated.
  19. @Matt Panzer Thanks for your response on that. I have had similar issues with the stairs object, and the weird thing is that the red rectangles persist even after removing or moving the stairs object. My fervent recommendation, as mentioned several times in the past: Do not construct parametric objects as meshes or NURBS! Construct them out of extrudes. Why? Because after you ungroup an object for custom editing, extrudes are the easiest things to modify. So much could be improved just by following this one rule. While you are (hopefully) rebuilding the stairs and door and window PIOs to be better, why not do it that way? If the parameters of previous versions of these objects are resident in their files, it should be easy to convert those to the new system. I would pledge to continue my Service Select for another 3 years if that can be done!
  20. I see what you mean. Have you tried putting the site model into a different file, and including it as a reference? I think you can then have different z = 0 elevations.
  21. Not sure if this works in both directions. If you move your model down using 3D move command, and increase the "Start contour offset" field in the General tab of the Site Model Settings dialog box, you can preserve the contour elevation labels.
  22. In my VW2020 site model, if I move the model vertically (using the Move 3D command), the contour labels do not change.
×
×
  • Create New...