[Richard]

JD

Thinking hard about possible workflows, something that twigged when considering a workaround for grouped emitter issue though not aligned to overcoming that issue, I wonder if I particular workflow may be possible?

Given that with arch models many materials work on a standard unit sizes and often maps for variations of the same material are of a set size, see the image below. The brick materials to be utilised in the model are all placed accurately using the same B/W low res map, variations to the SU materials are by colourising a new version of the first material and so on, each variation then linked during testing to alternative MXMs all using the same portioned and sized maps!

What I have bugger with is if one whats to change the assignment of the green brick from one face brick to another that is fine though if I want to change the assignment of geomtrey (adding more green elements - taking from the red or blue) I have to remap the chosen elements.

What I'd love to achieve is the option to map as done with one map all the brick feature though not count on the material assigning the MXM but rather grouped geometry. Much as is done in Studio!

So in the image below as example, all the brick areas would be the same colour when viewed in SU. Every brickwork element could then be grouped as proposed to be subject to possible variation, then the elected groupaassigned an MXM!

Possible? I think this could be a great feature for testing designs and refining material combinations!

[Half Life]

dynamic components may be the answer for you here.

Best,
Jason.

[JDHill]

What I'd love to achieve is the option to map as done with one map all the brick feature though not count on the material assigning the MXM but rather grouped geometry. Much as is done in Studio!

Entities inside a group which do not have an explicit material will inherit the group's material, so it already does work this way, no?

Other than that, I did not really grasp the exact meaning of your idea. I think you are basically saying that rather than MXMs being assigned as a function of their association with an SketchUp material, you would like that they could also be assigned on their own to groups, separate from the idea of SketchUp materials.

So, an MXM file path would be attached directly to a group's data, I suppose by right-click menu or similar. Is that even close?

[Richard]

dynamic components may be the answer for you here.

Best,
Jason.

Hmmmm? You could actually be right there mate! Have you tested dynamic components with such an option? And how this effects the outcome through the plugin?

[Richard]

Entities inside a group which do not have an explicit material will inherit the group's material, so it already does work this way, no?

Mate it does work like that yes! However only if the geometry has NOT been mapped! With these brick materials like a lot of arch materials map placement is critical and cant rely on a simple paint to default!

Other than that, I did not really grasp the exact meaning of your idea. I think you are basically saying that rather than MXMs being assigned as a function of their association with an SketchUp material, you would like that they could also be assigned on their own to groups, separate from the idea of SketchUp materials.

So, an MXM file path would be attached directly to a group's data, I suppose by right-click menu or similar. Is that even close?

Mate you got it spot on in your assumption! Items could be mapped with a simple scaling material to set critical map placement, in the example a simple B/W map of the brick / mortar pattern ie: All brickwork mapped with the same SU material. Geometry that may be assigned differing variances of brick could be grouped and via yes right click or via the "Assign to selected entities" button on the material section of the scene manager! However this later has an issue that an MXM can't be loaded then assigned presently without the selection of an SU material!

As mentioned earlier as maps from suppliers, those made by the users, or in collections tend to be of matching size for particular materials and this method of assignment would greatly leverage this aspect.

Again the current reliance on SU materials always defining MXM assignment requires any critical mapping to be redone to alter assignment other than global. I've got a great workaround to shorten this process though still can be a drag! As you can see above my model I have flying planes of my brick materials, these panels are set all from the same origin and set to projected, this than allows me to select a material from the corresponding flying plane / axis and paint to all selected same facing geometry and then sample and paint from the other plane / axis and paint to the others. For this type of building construction this is a very fast and effectual simple way to model / paint / map as the brickwork is the standard unit for sizing the exterior walls and the geometry can be push/pulled out using the map as the measurement reference, but still all this editing needs to be done manually for each test and has limitations as all the brick sills need to be replaced / edited with a new component
On another matter regarding material assignment, at present the plugin does not display the name of the linked MXM except for the tool tip which is ok until one wants to change the link, when browsing for a new material the current MXM name isn't displayed in the browser instead "choose file" then if one has to pick an alternative yet similarly named file no reference to the existing name is available and if one forgets to check via tooltip one has to shut out and reopen browse to allow for a quick confirm. Would be cool if either the current material name is either 1. displayed in the scene managed so to be visable whilst browsing or 2. the existing name appears in the browser inlieu of "choose file"!

[JDHill]

Hmm...I don't know. If it takes me an hour to understand (and I still do not think I do, fully), how long will it take someone else once it is implemented, with whatever caveats that would inevitably entail? Remember that the further we stray from the model that SketchUp defines, the more abstruse the interface (not just the UI, but the whole conceptual model) of the plugin becomes. And any suggestion which amounts to working around a modeler's native material methodology is something that makes huge warning bells go off.

That said, I have learned to guess that when I hear an idea that doesn't feel right, usually what I am looking at, is really a solution to the wrong problem. If so, then the first job is finding what the right problem is. In this case, I think it is more related to mapping, and really nothing else. Why? If I boil down what you are talking about, what it says to me is this: you want to disconnect your mapping from your materials. That is basically what you are trying to do with your current strategy (if I understand it correctly).

Therefore, I believe that the addition of custom mapping capabilities should likely eliminate this request entirely. Am I close here? If so, I think that rather than talking about circumventing SketchUp's idea of material assignment, we should be discussing how custom mapping should look when it is implemented, because as of yet, that is still a clean slate.

[Richard]

Mate certainly there is a way to simplify the process of getting SU to replace one material with another with the UV's sticking, it doesn't do that natively!

I don't actually see this as a complex option and it might be even an advanced option enabled by calling any map to be the base UV material for an MXM applied to a group! Ie in the example case maybe BRICKWORK[base] - the plugin then knows that any geometry painted so is subject to application by group!

Therefore it is an almost identical workflow as to where one replies on geometry painted with the default material and assigns an mxm via the scene manager, though in this case it is mapped to existing UV's!

Here is an image of what I'm suggesting:

- All geometry is painted with the same material "BRICKWORK",
- Geometry is grouped by elements (groups shown here all separated),
- Make selection of elements (groups) and apply mxm via link (no material applied to model),
- An elements assignment can then be edited without the need to re-map!

The point is that in testing often one may not want to change just the material but the order of materials and in arch scene this may well be many that come under the same option. Most commercial texture sets for example work on common sizes and scale, this would really permit the ease of testing where multiple uses of such materials are utilised. It certainly isnt an issue where the order of material use is predetermined, though this is the point of testing!

I have the MXM browser open as to show that then any material can be switched as all bricks are based on the same scale map!

[JDHill]

So, to try to boil this down to some real terms:

- you select a group
- right-click
- go to the Maxwell section
- you have an item: MXM Override
- you click that item
- you chose an MXM file
- at render-time, materials in the group are ignored, and the chosen MXM is used instead

This would accomplish what you are asking for, correct?

[Richard]

So, to try to boil this down to some real terms:

- you select a group
- right-click
- go to the Maxwell section
- you have an item: MXM Override
- you click that item
- you chose an MXM file
- at render-time, materials in the group are ignored, and the chosen MXM is used instead

This would accomplish what you are asking for, correct?

Mate that would be perfect!!!! Funny thing is one can currently apply a link to a group as show by the scene managers eye dropper tool on mouse over, it just doesn't have this override functionality on export.

at render-time, materials in the group are ignored, and the chosen MXM is used instead

Obviously maintaining UV's!

Mate thanks for listening to my obviously over descriptive rants and attempts to explain, just that this feature has the potential to save so much time in modeling as well as assignment / testing. The other plus I guess is that it further reduces the SU material browser load!