[eric nixon]

Brett it is you that doesnt understand much, or read properly. your posts are really quite rude.

You quote stuff you havent understood, for example; you say ' there are zero problems with make unique' in response to what I actually said;

'what happens when you un-click 'make unique'

And please stop saying repeatedly that I dont know what the issues are. At the beginning I said it would be a trade off and it is, JD has carefully described those very issues, I was concerned about.

If you quote someone adress what you quote.

Also, I never said it was hypothetical. The implication that i said it was is very annoying. Why are you on my case anyway, all I said initially is that MAX is bloated, it is... and I never said you were a geek... FFS were all geeks here

[Mihai]

I don't know Brett....even if this wasn't a question about rewriting large parts of the texture editor and if it would work in all the plug-ins....I don't see myself clicking any less in this system.

This is just my opinion but do I really reuse the same map in tens of materials in the same scene? Yes, but perhaps 1 or 2, and in those cases it's almost certain I won't use the same settings like contrast, invert etc. What I find myself often doing is changing the tiling in the same material to make sure all the DIFFERENT maps match in tiling value. I don't see in this instancing texture system how that would be solved. Because often, I do use the same map in different materials, but depending on the type of material I may use different tiling values for it, so again, I need a way to quickly change the tiling globally in the SAME material.

I can see how texture instancing could be useful, although for me personally I don't know by how much. What are some concrete examples?

It's been very tenable in Max for years

Alarm bells are going off in my head now.....sorry but Max as a usability and UI example.....Max has got to be one of the worse UIs of any 3D app. The amount of clicking to perform the simplest task is incredibly annoying. Perhaps this stemmed from a good cause - to give people every option and every control. But in the end there is no way to bypass it and you click click click to get to something.

[polynurb]

I can see how texture instancing could be useful, although for me personally I don't know by how much. What are some concrete examples?

i think it is not so much the mapping alone.
instanced&make unique could be useful for a set of items.

a practical example:

i was once working on the interior of an opera, and the client wished for a special kind of stucco texture for the tiers.
no chance with tiled textures, so everything was uv painted.

now the size necessary for the textures of the entire interior could never fit onto a single map, and i had to create 5 materials for the different parts of geometry, also for painting performance reasons.

you can imagine going through changes in such a material setup...
and i had the same issue with the chairs, too. some pixelated scheme with 6 different colors.
i got scanned samples of differently colored fabrics/leathers to try out.

so in this case, i would want to instance only the settings, but not the maps.
making unique would let me put in the map of my choice. and if i uncheck it it goes back to whatever version the reference contains;

speaking frankly i like much the work Jeremy put into the database manager and i'd wish something like it could become an integrated part of MXed. it is a pitty that it is only within rhino and Solid Works.

Why not develop a new (node based?) GUI on top of it to browse and manage the database and create materials?

if materials could be controlled via references in realtime (FIRE??) from MXed for any software package, it would give every maxwell user the same experience and flexibility in material creation and management.
most of the time all we would do in the host app. is setting up projectors and assign materials.

so MXed would become a tool-kit to keep track of changes and versions of materials with the added flexibility to instance components or entire materials for a per project basis which can be "made unique" where needed.

hope this theoretical stuff makes some sense

daniel

[Mihai]

i was once working on the interior of an opera, and the client wished for a special kind of stucco texture for the tiers.
no chance with tiled textures, so everything was uv painted.

now the size necessary for the textures of the entire interior could never fit onto a single map, and i had to create 5 materials for the different parts of geometry, also for painting performance reasons.

you can imagine going through changes in such a material setup...

But it seems to me what you are looking for here are master/child materials, rather than textures alone? You have 5 materials with identical settings, only the maps change, right? Change the master material and the children update? Otherwise I don't see how the ability to instance the texture editors settings would help much.

[simmsimaging]

Brett it is you that doesnt understand much, or read properly. your posts are really quite rude.

You quote stuff you havent understood, for example; you say ' there are zero problems with make unique' in response to what I actually said;

'what happens when you un-click 'make unique'

And please stop saying repeatedly that I dont know what the issues are. At the beginning I said it would be a trade off and it is, JD has carefully described those very issues, I was concerned about.

If you quote someone adress what you quote.

Also, I never said it was hypothetical. The implication that i said it was is very annoying. Why are you on my case anyway, all I said initially is that MAX is bloated, it is... and I never said you were a geek... FFS were all geeks here

I'm sorry if you are getting offended, but I stand by the idea that you are not understanding. I think it's important since it means we are not even really discussing the same things. Again though, I am not particularly interested in convincing you - I only replied to your post because of the possibility that others might not get it too, and cut potential support for instancing functionality. Regardless, sorry if I pissed you off, that was not my intention.

You are right in this one example that I misread your quote. I missed the "unclicking" make unique and read that as "clicking". It actually highlights my other point though, as there is no real way in which that makes sense. There is no "unclicking" a make unique button - it's a one way transition in every case of instancing that I am familiar with. Once you break the connection you need to re-instance the map/or whatever to recreate the link.

I am not on your case, I am on *a* case (to that point: you did not *just* say Max was bloated, you were arguing against a feature I think is important by indicating it was nothing more than bloat. A very different thing, and worth my commenting on.) This is functionality I really want to see added, it has zero to do with you personally.

Anyway - I think we've taken our discussion as far as it's going to go. Sorry again if you were offended.

/b

[simmsimaging]

Alarm bells are going off in my head now.....sorry but Max as a usability and UI example.....Max has got to be one of the worse UIs of any 3D app. The amount of clicking to perform the simplest task is incredibly annoying. Perhaps this stemmed from a good cause - to give people every option and every control. But in the end there is no way to bypass it and you click click click to get to something.

I wouldn't paint the whole program with the same brush Instancing is as easy as drag n'drop. It's simply an option you get that instead of automatically copying. Max defaults to whatever your last choice was (swap/instance/copy) so at most you have to hit "ok" Not so bad really.

http://screencast.com/t/VdGSYzGgx

Alternatively you can right-click the map and copy it, and then when you right-click to paste you have the option of paste as copy, or paste as instance. It adds one click again, but then all other changes are covered. For those who would find clicking "ok" too much hassle it could be set up so that middle-click dragging activated the instance/copy option, or some other thing along those lines. There are various ways to handle it I guess.

I'll address your other commen/question in a sec.

b

[simmsimaging]

I don't know Brett....even if this wasn't a question about rewriting large parts of the texture editor and if it would work in all the plug-ins....I don't see myself clicking any less in this system.

This is just my opinion but do I really reuse the same map in tens of materials in the same scene? Yes, but perhaps 1 or 2, and in those cases it's almost certain I won't use the same settings like contrast, invert etc. What I find myself often doing is changing the tiling in the same material to make sure all the DIFFERENT maps match in tiling value. I don't see in this instancing texture system how that would be solved. Because often, I do use the same map in different materials, but depending on the type of material I may use different tiling values for it, so again, I need a way to quickly change the tiling globally in the SAME material.

I can see how texture instancing could be useful, although for me personally I don't know by how much. What are some concrete examples?

It depends on the case. What you are talking about is more of a case of parameter wiring than actual texture instancing, which is a different thing and also hugely useful. I often use both, and often in the same material. I agree that the image properties (as they are called in MXED, brightness, contrast etc) are often unique in to different slots, but the projection parameters would be instanced. That is a common case - where you might use variations on a black and white map in roughness, and anisotropy (just as example) and use them several times in one material (say 3 BSDF layers) and again in two different but similar materials. It is not hard to have a case where one map is used 10 different ways. In such a case projection parameter instancing is the thing, but without a separate "container" for the image properties it is more a question of parameter wiring (linking the tile values etc) than a true instance.

However, it's also possible to need to instance the image properties. Think of a multi-layer material where the same weight map is used to blend several layers, and even across several variations of the material. In that case the image properties would be usefully instanced too. In such case you can use a "true" instance of the whole texture as it is currently defined in Maxwell, or you would need a way to instance the "container" I was speculating about.

While I understand your point that global tiling can be useful, in my own material work that would be a very rare case. It is far more common for me to use several different maps in a single material and each one can have wildly different tiling values depending on the actual maps. As Polyxo pointed out - that may not apply to custom painted maps (which should not tile at all), but then neither version of parameter instancing is relevant

Being able to instance at several levels (bitmap itself, projection, image properties, BSDF, material layer) allows for a far more fully developed material workflow. Not everyone would need it, but it would be a godsend to those of us that do. As a case in point here is a carpaint type material of mine - I'm showing the node view just because it provides a clearer snapshot of the many levels of interconnectivity:



This is a complex one, but the legwork up front in building it has made for an extremely verstatile material for me. That level is not *super* commonly needed, but it's a case that shows instancing/wiring at pretty much all levels, and at slightly less complex levels it is far from rare.

Here's a more common one - this is for a slightly worn chrome:



The parameters in yellow at the far left would be what I call parameter wiring: tiling values for the actual projection. The next two levels are not really reproducible in Maxwell, but essentially I am using 12 bitmaps blended into a Composite map (which is what I would call a ``container`` shader). That Composite just allows me to blend the bitmaps much like a Photoshop document with all the bitmaps in various combinations of overlay, multiply mode etc. It shows you the kind of functionality that I think it very useful when you can separate the instancing of projection versus image properties.

Further over you have the equivalent of instancing that final image map (the result of the composite) into a few texture slots of a material (that would correspond to a BSDF layer and it`s slots). In the top one it`s actually nested in yet another node that lets me change brightness/contrast.

The final product in this example is a blend material, would correspond to a normal Maxwell material, where each sub-material is like a Layer in MXED.

It would not be hard to think of a case where most of this entire node diagram could be usefully instanced to yet another chrome - say one that had some typography in it, or that was supposed to be dirty or more shiny, or more worn, etc. etc. In that case being able to instance MXED material layers between different MXM's would be necessary.

Clearer now?

[Polyxo]

@ JD,
thanks for your reply, now I understand quite a bit better what you have in mind!


Apart from the instancing being discussed here I think the Maxwell-Default Material-Editor would greatly profit from some GUI Elements
your Rhino-Users already know, at least in parts:

1) Image-Preview for Channel-Maps instead of the generic, non telling Icon Mxed uses.
It was very cool if such a Thumbnail visually reflected definition-overrides per channel.

2) Show all Image-Controls at Top-Level if somehow possible. (Image-PreviewTiling/Offsets/Colour-Corrections)
I really loathe having to drill down for the most needed stuff. Even if one does not need to do changes:
It's just great that one can see at first glance that everything is fine. Inside Mxed it's terribly clicky inside a Multi-Layer-mxm
to locate and fix the single map which has the wrong tiling setting applied. This really doesn't work at all for me.
To me using less space would not count as a valid argument to establish a hierarchical GUI in Mxed.
We all have large screens and often enough several of them.

I personally don't feel intimidated by Node-Based Editing but would not at all like to use it for Rendering.
My personal demands are too limited to justify that level of base-compexity in Material-Setup.
However I can generally understand this desire by High-End-Users. Maybe doors could be opened that such GUI's
could be hooked up by third parties?

[Mihai]

2) Show all Image-Controls at Top-Level if somehow possible. (Image-PreviewTiling/Offsets/Colour-Corrections)
I really loathe having to drill down for the most needed stuff. Even if one does not need to do changes:
It's just great that one can see at first glance that everything is fine. Inside Mxed it's terribly clicky inside a Multi-Layer-mxm
to locate and fix the single map which has the wrong tiling setting applied.

This is what I was talking about and for any materials that have a bump/normal/roughness/spec map derived from a base diffuse map, I often find myself changing 7-8 different tiling parameters and they all need to be the same. So these aren't really exotic materials....anything that's tilable basically like wood floors, walls, concretes etc.

Brett, believe me I understand completely the benefits of a node based system, in fact I already have this with the Softimage plugin. You get this instancing 'for free' because you can reuse a component and hook it into several others. But I can't imagine a user trying to keep track in their heads what is connected to what if it's not a node based system. So I guess the question is, how much of the texture picker can you separate like this, not having a node based system, and still keep it usable... Maybe there are better approaches but this is really another discussion I think.

It seems we are discussing three different (but related) things:

Texture instancing, I understand users would look for a way to reuse the same texture settings in different texture slots and/or materials. This could be done and it would still be pretty clear, without a node based system.

Ability to define globally some texture parameters per material, such as global tiling. Personally I think this would save a lot of time in many material setups.

Decomposing the material system into building blocks (Layer, BSDF, Texture settings, Emitter etc) and reusing them as one wishes. Requires a node based system.

[Polyxo]

Mihai,
fwiw....for basic synching of values JD already has a very simple system in place in Rhino.
I personally have more materials where Channel-Textures share tiling/offset settings than deviating settings from Channel to Channel.
For what I need this works very well.
It actually works as a global Tiling Interface - one can set all Tiling values of 4 or 5 Layers at once and if there's one or two maps which
need other values one has to do that manually. But would stay that way with per Channel-Overrides of Global-Settings, no?

[polynurb]

Decomposing the material system into building blocks (Layer, BSDF, Texture settings, Emitter etc) and reusing them as one wishes. Requires a node based system.

exactly.. but it would then well serve any of the simpler tasks too.

imho, such an approach opens a completely new set of possibilities.
think about MXM collections variations in ral, pantone created in minutes, entire sets adjusted in seconds.

for rhino it may work once 5.0 is final.
please see here: http://www.maxwellrender.com/forum/view ... 05&t=37954

[simmsimaging]

Brett, believe me I understand completely the benefits of a node based system, in fact I already have this with the Softimage plugin. You get this instancing 'for free' because you can reuse a component and hook it into several others. But I can't imagine a user trying to keep track in their heads what is connected to what if it's not a node based system. So I guess the question is, how much of the texture picker can you separate like this, not having a node based system, and still keep it usable... Maybe there are better approaches but this is really another discussion I think.

I agree that a node based systems makes it *easier* to work with complex materials, but remember that the node based system only got added to Max one or two versions ago. It is not necessary. Perhaps the better way to think of it is this: you can already build really complex materials in Maxwell and if the maps are not instanced you have to do even *more* work of actually keeping track of which parameters *need* to be changed across all the maps. Only now you *have* to do it by hand so you have to remember all that complexity every time you make a change, instead of just once when you set it up. Not having instancing makes it harder, not easier. Having nodes just makes it easier to visualize the entire system.

It seems we are discussing three different (but related) things:

Texture instancing, I understand users would look for a way to reuse the same texture settings in different texture slots and/or materials. This could be done and it would still be pretty clear, without a node based system.

Ability to define globally some texture parameters per material, such as global tiling. Personally I think this would save a lot of time in many material setups.

Again, this is okay, but consider your example of a wood floor. Normally I would have 3-4 maps that would use this (say derived from the same diffuse, i.e Arroway) but very often I would have a *different* map to create scratches and bumps in the floor coating and yet another for the roughness to make the glossiness variable. Those maps would often need different tiling values from the 3-4, and even from each other. This kind of thing would render the entire global systems useless for that material/layer. The only answer for what you are talking about, that isn't limited this way, is parameter wiring. This is possible in Max, but as far as I know it can only be doing with the node-based material editor or some of the animation controls. Is there a way to implement some form of parameter wiring in MXM's?

Decomposing the material system into building blocks (Layer, BSDF, Texture settings, Emitter etc) and reusing them as one wishes. Requires a node based system.

I guess you could look at it that way. I think its more accurate to say that we *already* have a building block system for materials (Layer/BSDF/Texture settings etc) - what we are talking about is adding one , maybe two, additional sub-blocks to the texture settings, and a way of creating references between building blocks used in different areas. Obviously it's more complex at the programming level, but it is not really adding something wholly new in Maxwell. Each BSDF layer in any materials or any two materials has to derive it's values from somewhere. At current the user enters those manually (or uses defaults). All we really need is a pointer that says "get these values from X other BSDF instead". Clearly it needs the ability to go both ways (the difference between an instance and a reference object in Max).

[rusteberg]

i'm wondering if theres a way to create a separate "asset management" window where the user can propogate instances of texture maps with tiling and correction control located within each asset itself given a unique ID.

for example, if i have 5 shaders in a scene which rely on the same maps for specular, bump, displacement, etc. instead of going through all 5 materials, swapping values at each layer slot the texture is used, the user would be able to change the values within a central location "on the fly".

being able to duplicate a texture within the "asset management" window with control over tiling and correction would seem highly practical. the true efficiency would lie in being able to right click on a texture within the "asset management" window and select the slots calling that texture with the ability to "swap" between the ID's listed in the "asset management" window.

for example, if i had a material with 3-4 layers calling on texture "A" in several slots and I wanted to do a series of test renders which depend highly on texture "A", i could duplicate texture "A" within asset management into B, C, D where each image feature of the texture is centrally located. right click texture A > swap with texture B, C, or D.

this way you're retaining the notion of "instancing" within a central location versus having to keep track of where/what is instanced within stacks scrambled all over the place.....

just some thoughts...... got confused reading through some of this and not sure if it was something already brought up....

alternatively, the ability to load .psd into texture slots with ability to define layer or treat as collapsed to later change which layer is used for specified .psd within a central location...... gotta go. da choppa is waiting....

[simmsimaging]

Personally, I think a totally separate texture "pool" is ok, but adds unecessary complexity.

It's important to see that instancing texture maps (either the bitmap itself, or the parameters) does not *add complexity*. This idea that it will be hard for the user to track what is connected to what if you instance things keeps coming up, but this simply wrong.

It's a misconception, I would guess, based on either not understanding the instancing workflow, or getting thrown off by how the complicated schematics of an instanced texture setup *appear*. All those flowing lines look like a mess, I agree.

However, the misconception is this: the complexity in all those cases comes *entirely from the material requirements*. It isn't instancing that makes it complex, it is all those complicated relationships which are dictated by how you need the material to look.

The only thing that is different is that all the relationships need to be manually updated in one case, and are automatically updated in the instancing scenario.

If that kind of repetitive use of the maps is required by the material, then *all* the complexity is there *anyway*, with or without instancing. But anytime you make a change it needs to be replicated manually across all versions. Keeping track of that, and not making any mistakes while doing it, is vastly more complicated.

If you set those relationships up with instances at the outset you do basically *nothing* more than you had to do anyway, and every other time you access those parameters you need only do it once. It is *way* simpler, even though it may *look* more complicated when you see it laid out in a schematic form.

If at any point you need to separate out a single map from the instancing you can (in most cases) redefine it as unique and then it's parameters are open to change on an individual basis. There is no such thing as making a map (or whatever) 'un-unique' again. If you need an instance again you would just re-copy (as an instance) the version you wish to replicate again. Simple as pie - and involves nothing more than you would have to do anyway, even without instances.

Taking all this to the next level - instancing BSDF's and layers between materials - is exactly the same.

Perhaps there is some way to work with the current .MXM format for that? It's currently possible to load/share embedded MXM's within materials, and the referencing system is kinda in the right vein I think. Anyway, just wondering if there is something to the idea of extending that format to avoid major changes to the MXED core?

/b

[feynman]

Before programming an entirely new material editor model, maybe some basic but ever so useful features - that would be in tune with the existing model - could be implemented (see my earlier post with images to explain what I meant). Rotating, scaling, offsetting, RGB adjusting of maps plus instant preview of these changes in the material editor, and copying of selected parameters across multiple maps or multiple materials...