Problem with controlling wall texture by class in VW 2024

[EliM]

Our office has always used class to control wall textures, but this functionality seems to be severely diminished in VW 2024. In the below screenshot, I have a wall in a class with the wall textures specified as a shingle texture. The wall does show this texture BUT the Render settings in the Object Info panel do not acknowledge the texture and suggest the texture is None. The problem with this is then all the supplemental settings are greyed out and I can't, for example, adjust the texture vertically to get my coursing where I want it.

 

Our workaround so far has been to manually override each wall's texture in the Object Info panel, which then allows us to control those supplemental settings, but this is far from ideal if we want to be able to quickly change all walls of a particular class from one siding to another. 

 

Is this a VW 2024 bug, or is there some new setting turned on in VW 2024 that is causing the issue and we just don't know about it. Thanks in advance to anyone who takes the time to provide insight!

VW 2024 Wall Texture Issue.vwx

[line-weight]

This doesn't answer your question and may not be a helpful comment, but is there a reason you control texture by the class of the wall object rather than the classes of the wall's components? Most walls have a different texture each side - presumably you don't want the shingles appearing on your internal wall surfaces.

[Jeff Prince]

4 hours ago, EliM said:

Is this a VW 2024 bug

EDIT:I guess it is a bug in that specific use case.

 

If you are using simple one component walls, I could see using a by class texturing methodology to move quickly during a concept phase.  However, you aren't doing that, you are using complex wall styles with many components.  So, you should render them "by component" and set your textures within the component settings (in my opinion).  If you have a building that has multiple exterior finishes, doing them "by class" could become very cumbersome compared to managing this all with Wall Styles, and perhaps materials if you were so inclined.

Edited April 16 by Jeff Prince

[Tom W.]

Nevertheless @EliM is correct to say that the behaviour has changed in VW2024, no doubt connected to the introduction of per face/per component texturing of Walls. In previous versions the part of the Wall would show the texture being used + allow mapping. So not unreasonable to describe it as a bug...

[Jeff Prince]

That's interesting, I hadn't noticed that small difference.

This is actually a pretty significant issue for people who are doing as @EliM.

I could see a use case where you have a wall style that is defining all the components for spacing/construction method, but you want to render the outermost finish by Class so you don't have a bunch of wall styles for a change in color or texture, but not the type of component (example: different kinds of CMU walls or Stone Veneer).  Still, using that methodology makes scheduling and takeoffs a bit more difficult.

It wouldn't be the first time we have had to completely change the way we do things because of a small change to object behavior 😞

 

[EliM]

@line-weight We in the past have controlled texture by class for exactly the reason @Jeff Prince describes in his second comment, ultimately to avoid management of a bunch of different wall styles that are the same in every way but the finish.

 

@Tom W. It does make sense that this is related to per component texturing of walls. I will try reporting this as a bug so that just maybe the developers can add this functionality back in. In the meantime we will adjust our workflow...c'est la vie!

[Tom W.]

It does feel like per face/per component texturing needs some extra work... Currently you can apply texture overrides + there is nothing in the OIP to tell you you've done so: the only way to check whether the textures you see on the Wall are the style textures or not is to compare what's in the Render tab for the instance with the settings for the style. And the only way to revert to the style textures after applying overrides is to replace the Wall style for those instances with 'Only replace default textures' disabled: 'Remove Texture Override' is greyed-out when you right-click on the parts/component in the OIP. I've been meaning to post VE/VBs for this.

[station]

I am finding this an issue as well - controlling texture and mapping in the object info was workable. I am not seeing overrides as a workable option.

[billtheia]

I am having the same problem.  Would be great if VW2024 allowed mapping of class-assigned textures, as previous VW versions have done.

[EliM]

Just found a related issue. If you're controlling wall texture by class, you also will not see the surface hatch in a hidden line viewport (which our office uses for elevations). You first need to do a manual override for the wall texture for each wall object if you want to see the surface hatch.

[AlanW]

@EliM

Hi See attached,

Hopefully i got the question correct.

 

Refer attached i noticed that the wall and components were not set by class. need to click the attribute panel to set by class also. Sometimes you need to switch between object and components to reset the script. I had to go from iso view to plan view and back to make the wall show correctly.

 

HTH

VW 2024 Wall Texture Issue_240516.vwx

[EliM]

Hi AlanW, thank you! If I understand correctly, you set the wall style to render texture by component, set the cladding component to render by class, and set the texture of the class of the cladding component to the appropriate cladding texture. This isn't exactly what I was looking for, but it could very well be pointing to the way our office ought to adjust our workflow going forward. To really work the way we want it, we would change the class of the cladding component to the object class, and then we could use one wall style to express different siding textures by changing the class of the wall objects.

[billtheia]

Does VW still monitor this forum & reply to comments?  It would be helpful if someone from within the company could chime in with an explanation/solution.

[E|FA]

3 hours ago, billtheia said:

Does VW still monitor this forum & reply to comments

VW does not officially monitor & reply to the forum.  For better or worse, the forum is primarily for users to interact with each other.  Some VW employees do take the time to comment.  You can reach out to VW tech support and/or bug submission directly, although response there is not always great (see other forum threads).

 

3 hours ago, billtheia said:

It would be helpful if someone from within the company could chime in with an explanation/solution.

Agree.

[JuanP]

15 hours ago, billtheia said:

Does VW still monitor this forum & reply to comments?

Although we monitor the forum closely, we don't respond to every post because we often need additional information. During business hours, please feel free to contact our technical support team via https://customers.vectorworks.net/support, and they will be happy to assist you.

[billtheia]

Thanks, Juan.

 

It's been a while since I used this forum.  In the past, it seemed like VW was more engaged here.  It is unfortunate that we are now forced to go through the cumbersome process of filing a support ticket for each and every problem we encounter with VW.  Also seems like a missed opportunity for VW to engage with its users.

 

I have submitted a support request.

 

BTW, the link you posted does not seem to work.  I had to copy and paste the text to get it to work.

[Matt Panzer]

I see this issue as well and submitted a bug (VB-204858).

Thank you for brining this to our attention and apologies for the delay us in looking at this.

[billtheia]

Thanks, Matt.  Does that mean this is a bug and a fix will be forthcoming?

[Matt Panzer]

All I can say is that it's a high priority bug and should be addressed soon.  How soon I cannot say...

[billtheia]

OK.  Thanks.

 

Glad to hear that it is a high priority.