grahamcase

Thanks Tom - Bug report submitted! I don't mind modelling the fascia, But I usually find it's more of a hassle when dealing with flat roofs - I'd usually model a parapet (with a wall), and render that with the fascia texture, keeping the slab rendered by component, but with these modular boxes, the roof is usually a cap, and yes, I thought this would be a quicker way to model everything most accurately 🙂

Hi Tom, Thanks for taking the time! By Component rendering works as expected - I have a tapered layer (tapered joists), and two connected drains on either end to achieve the roof shape, while maintaining a flat ceiling. Changing the thickness of the top component does not seem to change anything. As for the slab drainage, like I said, I haven't done anything crazy, just connected two drains on either side to slope the slab away from the centre. I also get this kind of rendering when placing just one or two drains. A copy of the problem roofs attached! At the end of the day, this isn't a huge issue - I can work around the roof not rendering exactly correctly. It's just a strange interaction. Oh, and when the Side texture is mapped with Auto-Align Plane, it wraps around the top, too. Thanks again! Roof Texture issue.vwx

I have this weird, yet not really TAHT important rendering bug (VW2024 on a 2020 Retina 5K 27-inch iMac running Sequoia 15.6.1). When I add drainage to a slab/flat roof and try to style it using the Object Style mode, the top does not render properly, as you can see in the attached screen shot. Vectorworks can't seem to figure out that the roof is tapered, and tried to style it with a horizontal plane, that intersects the roof in two bands. No matter the Map Type, Vectorworks can't map this texture properly. If anyone has any suggestions (I'd really like to keep it as a slab with drainage). Thanks!

Thanks for the quick follow up, Matt! To clarify my wording when I said "...until VW decides it's no longer an issue" I literally meant the program, and not the company or the people (like yourself) working on it, so sorry if my wording was perceived as dismissive in any way. I fully recognize this is one of those issues that are almost impossible to solve because it's so intermittent - while it's frustrating from an en-user standpoint, I can only imagine that it has caused a few bald spots on the developer side from it's insistence on not being consistent. FWIW, visually (from the door appearing not to be hosted and with that strange line at the midpoint of cutting objects) it seems like the walls are doubling back on themselves, and meeting at the midpoint between cutting objects - the program then sees the cutting objects cutting through one part of the wall (so showing up as an object in a wall in the OIP), but since the object can't cut through more than one wall, it gets covered by the part of the wall that has doubled back. Anyway, that's just my theory, and offers no help why the wall might do that! Thanks again!

To follow-up from yesterday. Without closing Vectorworks last night when I went home (though I did close the file), I came into work today to output some drawings. The graphical issue persisted through a save, however when I needed to add a new door the graphical issue did not occur for the newly added geometry. I was also able to fix the existing issue in the file, though the same process failed for me yesterday I worry that this issue will persist, as it seems to be intermittent, short-term, with no sensible way to fix it, until VW decides it's no longer an issue.

Just wanted to jump in to say that I am also having this issue in VW2023 with a file that was started in VW2023. Same issue - if more than one object is attached to a wall, they all graphically disconnect, while still saying in the OIP that they are "in wall". So if I have more than one door in a single wall, they "become disconnected" yet still say in the OIP that they are "Doors in Wall". This issue was not always present in this file, indeed it just cropped up into the file today! More than just doors/windows, though, if I have a door in a wall (Wall A) and another wall (Wall B) is T-Joined to Wall A, the same graphical issue will happen to the door located in Wall A. Does not appear to be an issue with L-Joined walls. The easiest solution is to split walls that have long runs and multiple doors, and just not T-Join other walls, but this is a nonsense solution, I think we can all agree. Unfortunately, neither dhaun's solution, to toggle on/off the "Create Niche for Space Objects" does not solve this issue, nor @Matt Panzer's Move by (0,0) trick work for me. ONE THING I HAVE NOTICED, in both my drawings and the examples I've seen in this post is that when this issue happens, VW creates a strange line in the Wall Geometry at the midpoint between the two cutting objects. This is visible in 3D modes only in wireframe, so understandable that it seems no one has noticed. I have attached screenshots to demonstrate. In both images, the wall is a single wall, no splits. In the "working as intended" example, you see a clean wall (in 3D) with no unnecessary lines - just two doors hosted in the wall. In the "problem" image, you see a strange line at the midpoint between the two hosted doors. It looks like a split in the wall, however it is an artifact produced by the issue causing the graphical glitch. I have also attached a Birdseye wireframe view of the glitch - the line you see that looks like a split in the walls should not be there: that is a single wall, and not two separate walls. Sorry to be so verbose, I just want to emphasize this issue. I hope that this helps the VW team pinpoint and solve this issue. I am happy to DM my file if someone on the VW team feels that would help. Graham