Wall Style Class Overrides

[Mark Aceto]

I almost don't want to ask this question because of the rabbit hole of redundant troubleshooting but here goes... 

 

Suffice to say I have checked every single container class, wall style attribute, turned off component classes, and on and on and on... and yet, I cannot override wall classes in any way shape or form. Not the container classes. Not the component classes. All class attributes are set to use at creation.

 

My only guess is that it's the materials nested inside the components that are somehow persisting even when I have the component classes set to invisible.

 

I'm beyond frustrated, and ready to go back to using data viz (which regenerates that useless legend every time).

 

Edited March 17, 2021 by Mark Aceto

[line-weight]

I am in a similar position. VW 2023 SP3.

 

I want a (styled) wall to appear with a certain renderworks texture, in a renderworks viewport, via a class override

 

The container class, and all the component classes, are given the over-ride for the relevant viewport.

 

The wall changes colour but the texture is not there.

 

I too suspect materials (which I don't currently use) are getting involved.

 

Here's the wall object's OIP, note the "material" cube icon appearing there hence my suspicions

 

 

Here's the relevant wall style:

 

 

Here's the settings for the relevant component of that wall style:

 

 

Note the "use material" checkbox is *not* ticked and texture is by class. So it should take the texture of my class " *materials-masonry-brick". And that class is over-ridden in the viewport with the texture I want. As is the overall "container class" for the wall object.

 

Is there anything I can do here or is this another workflow broken?

 

 

[Tom W.]

Can you post a file that is displaying the problem? I am using Materials exclusively for Wall components these days but nevertheless it is a bit disconcerting hearing what you're describing 

 

[line-weight]

28 minutes ago, Tom W. said:

Can you post a file that is displaying the problem? I am using Materials exclusively for Wall components these days but nevertheless it is a bit disconcerting hearing what you're describing 

 

Hastily cobbled together example file attached.

 

Two things actually going on here:

 

- The over-ride is not working properly on the wall object - but I notice, it is working on the ends/sides*

 

- It's also not working on the "roof face" object.

 

*gives a possible clue as to what could be going wrong...have to go out for a bit but will investigate later

override.vwx

[Tom W.]

Thanks am stuck in a field doing percolation tests at the moment so will look later but first thing to ask, is the Wall set to render by component rather than by object?

 

 

[line-weight]

45 minutes ago, Tom W. said:

Thanks am stuck in a field doing percolation tests at the moment so will look later but first thing to ask, is the Wall set to render by component rather than by object?

 

 

It is - as is the wall face object.

[Tom W.]

If you change the Map Type for the Wall from Plane to Auto-Align Plane it seems to then behave normally but I can't seem to override the Roof Face textures whatever I do... Weird

[Tom W.]

I have tried my own styled Roof Face in a new file + can't override the class textures there either. Tried in VW2022 + it's the same. Wow. Data Viz + Materials works fine though. Makes me realise how little texture overriding I actually do so have no idea when this last worked.

[line-weight]

5 hours ago, Tom W. said:

I have tried my own styled Roof Face in a new file + can't override the class textures there either. Tried in VW2022 + it's the same. Wow. Data Viz + Materials works fine though. Makes me realise how little texture overriding I actually do so have no idea when this last worked.

 

Eurghh. Various key workflows broken for me then. It wasn't a problem in VW2021. I'd have thought class overrides were a fundamental enough thing that it's something we shouldn't have to worry about losing without warning.

 

Should I be able to replicate class texture overrides using data vis or do I have to start using Materials too?

[Mark Aceto]

The nice thing about data vis is that you create the rule one time, and then turn it on or off across every layer and viewport across every file… vs individually fiddling with this on a per viewport basis. I bailed on overrides after the above, and haven’t looked back. I feel your frustration, so hopefully this provides some hope for a better future (workflow).

[line-weight]

So. In the course of working out how to make data vis work, I found I could actually fix the wall object, so that class override works on its components, by

 

(1) Making sure the "texture" box is ticked, in the relevant class settings (it wasn't previously) as per screenshot below

(2) Resetting the wall object using a 0,0 move.

 

 

However, a similar fix does not seem to work for roof face objects.

 

 

Moving on to data vis - I have basically got this to work. There's an additional bit of setup that has to happen though, where I have a container object with [container class] and then objects within it with [material class].

 

Using class overide, the attributes of the [material class] are determined by that class, not the [container class].

 

But using data vis, what happens to objects with [material class] is also determined by the [container class] of whatever container they are within. So I have to set the criteria to take account of both. Basically tell data vis to exclude any [container classes] where I want to fiddle with attributes of objects inside them.

 

This is kind of ok for the particular use case I'm dealing with right now ... but I foresee potential to cause problems with other things in the future.

 

Certainly, even without that issue, converting large numbers of viewports to work using data vis instead of class over-rides, is going to be a tedious task necessary in any files I want to move from VW2021 to 2023.

[line-weight]

On 3/17/2021 at 3:25 AM, Lunar Waneshaft said:

data viz (which regenerates that useless legend every time).

 

 

Don't suppose you have found a way around this?

 

Each time it has to be deleted manually from the annotations space, right?

[line-weight]

17 minutes ago, line-weight said:

However, a similar fix does not seem to work for roof face objects.

 

 

 

 

Well: the opposite seems to apply to roof face objects. If you leave that "Texture" box unticked, then class overrides work. If you tick it, class overrides stop working. Fancy that!

 

This kind of consistent and predictable behaviour is what we all love so much about VW of course.

[Tom W.]

24 minutes ago, line-weight said:

 

Don't suppose you have found a way around this?

 

Each time it has to be deleted manually from the annotations space, right?

 

See:

 

 

[Tom W.]

31 minutes ago, line-weight said:

So. In the course of working out how to make data vis work, I found I could actually fix the wall object, so that class override works on its components, by

 

(1) Making sure the "texture" box is ticked, in the relevant class settings (it wasn't previously) as per screenshot below

(2) Resetting the wall object using a 0,0 move.

 

For me changing the Map Type for the Wall had the same effect (see comment above).

 

11 minutes ago, line-weight said:

Well: the opposite seems to apply to roof face objects. If you leave that "Texture" box unticked, then class overrides work. If you tick it, class overrides stop working. Fancy that!

 

Good catch but the result of this is that your component does not display the original texture on the design layer right? Or because you're using solid fill colours instead this doesn't matter? 

[line-weight]

1 minute ago, Tom W. said:

Good catch but the result of this is that your component does not display the original texture on the design layer right? Or because you're using solid fill colours instead this doesn't matter? 

 

Yes, it doesn't solve the problem unless you don't want any textures on roof face objects in the design layer. So, if you were using solid fill colours only it wouldn't matter. But I usually want to use a mixture of both (or solid fill colours might change to textures as the design develops)

[Mark Aceto]

3 hours ago, line-weight said:

Don't suppose you have found a way around this?

 

Each time it has to be deleted manually from the annotations space, right?

 

Someone generously wrote a script (attached) that can be assigned a shortcut for quickly deleting the legend. On that note, keep in mind that Mac users have the CTRL key available for a full set of additional shortcuts, so you won't have to find some ridickydonk five finger death punch to avoid replacing an existing shortcut.

 

Delete DV Legend.vsm

[Mark Aceto]

BTW of all the autogenerated classes, the DV Legend should be one of them. I'll submit a VE for this because it should gain enough traction to actually happen sooner than eventually someday maybe.

[Tom W.]

I think we really need to be able to designate a DV as non-legend-generating before the fact. In the bulk of cases it simply shouldn't exist in the first place.

[line-weight]

1 hour ago, Lunar Waneshaft said:

 

Someone generously wrote a script (attached) that can be assigned a shortcut for quickly deleting the legend. On that note, keep in mind that Mac users have the CTRL key available for a full set of additional shortcuts, so you won't have to find some ridickydonk five finger death punch to avoid replacing an existing shortcut.

 

Delete DV Legend.vsm 5.92 kB · 1 download

 

Yes, @Tom W. pointed me towards a thread about that, above. There's another one too, which I've already successfully used.

[line-weight]

So...

I can see that I can use data vis to substitute "texture_X" with "texture_Y".

 

However... what if I want to substitute a whole load - if I want to substitute "texture_X1" with "texture_Y1" and "texture_X2" with "texture_Y2" and so on up to substituting "texture_X99" with "texture_Y99" ?

 

There's not really a way to do that, right?

 

 

 

[Tom W.]

17 minutes ago, line-weight said:

So...

I can see that I can use data vis to substitute "texture_X" with "texture_Y".

 

However... what if I want to substitute a whole load - if I want to substitute "texture_X1" with "texture_Y1" and "texture_X2" with "texture_Y2" and so on up to substituting "texture_X99" with "texture_Y99" ?

 

There's not really a way to do that, right?

 

 

 

 

I don't think you can do this within a single Data Viz. You can replace multiple different textures with one single texture but not each one its own texture. Might be time to start using Materials...

[Mark Aceto]

23 hours ago, line-weight said:

So...

I can see that I can use data vis to substitute "texture_X" with "texture_Y".

 

However... what if I want to substitute a whole load - if I want to substitute "texture_X1" with "texture_Y1" and "texture_X2" with "texture_Y2" and so on up to substituting "texture_X99" with "texture_Y99" ?

 

There's not really a way to do that, right?

 

Might be able to do that with Function criteria.

 

If not, should be able to do it with multiple data vis selected.

 

One of the caveats of data vis is there's currently no way to save a "set" of a multiple data viz. Btw when selecting multiple data vis, there's a stacking order of operations. From memory, I don't believe Saved Views are tied to data vis but it would be great if I'm wrong. Obviously, SLVP's are DV independent, so you could stack all manner of combinations of multiple data vis in each viewport.

[Tom W.]

3 hours ago, Lunar Waneshaft said:

Might be able to do that with Function criteria.

 

There is Material Function criteria but not Texture...

 

3 hours ago, Lunar Waneshaft said:

If not, should be able to do it with multiple data vis selected.

 

Correct, but not very practical if replacing 99 textures as per @line-weight's post...!

 

3 hours ago, Lunar Waneshaft said:

I don't believe Saved Views are tied to data vis but it would be great if I'm wrong.

 

Saved Views will save multiple DVs which is fine on the design layer but it'd be great to be able to save a set of DVs, then you'd be able to apply multiple DVs to a SLVP with 2 clicks + not have to try + remember the combination each time.

[Mark Aceto]

3 hours ago, Tom W. said:

Correct, but not very practical if replacing 99 textures as per @line-weight's post...!

 

If you're havin' girl problems, I feel bad for you, son