[JDHill]

I would like to have a texture list that worked similar to how the materials list does. For convenience, I'll arbitrarily define some terms:

• file: image.jpg
• texture: a file path, with a set of tile, etc, parameters
• map: a slot in a component, i.e. Reflectance 0 in a BSDF

I'll just use these, so the rest can make sense. Starting with an empty BSDF, you click its Refl0 map button; one of two things happens: a) you select an existing texture from the list, or b) you create a new one, by selecting a file. In the latter case, a new texture is added to the texture list. The Refl0 map is then linked to the chosen/created texture. All well and good: maps are linked to textures in a list, and you can modify textures from a central location.

However, you do not want to have 2300 textures in your list, one for each variation of tile x for a given file. Therefore, you need the ability to override texture parameters on a per-map basis. This implies that the texture-editing UI is operating, at any given time, within the context of a texture definition, or of a specific map. To edit a texture definition, you select it from the texture list. To override, in a specific map, parameter values defined in its linked texture, you click the map's button. When editing at the map level, you can switch over to editing the texture definition instead, if you like. Also, when editing at the map level, it is implied that individual parameters would provide a way of being 'unset', allowing them to once again inherit values defined in the linked texture definition.

Not sure if I'm painting a clear picture of what I'm thinking, in terms of putting the abstract idea of texture instancing into more concrete, Maxwell-centric terms.

[itsallgoode9]

i hadn't thought of it before but this is something that would be insanely useful. Both in preventing errors and general workflow speed. Has anybody added this into the wishlist thread yet?

[simmsimaging]

Yeah, geeks always want more buttons to press, bless em

The issue is that the efficiency gained by not having to re-type things, is lost by both making the initial link and subsequently deleting that association as you need to make further changes. Its becomes another issue to think about while adding some inflexibility. Occasionally it would be quite useful but overall not owrth it, so I think NL chose not to implement it.

Sorry mate, but it's very clear to me that you do not understand what it's all about. The utility of this workflow is not hypothetical: I use it all the time with other engines, and its a very common approach where it's technically possibnle. I'm hopefull that NL will get what I mean, and that we get some more users to chime in.

[simmsimaging]

i hadn't thought of it before but this is something that would be insanely useful. Both in preventing errors and general workflow speed. Has anybody added this into the wishlist thread yet?

I think I asked for it before. I know I discussed it with someone - I think Mihnea and he pointed out that it's already possible to instance maps in the Max plugin. However, until the plugin replicates all of what I can do in Studio I would like to see the ability in both.

[simmsimaging]

@JD: I *think* I followed that
It depends a bit on how much sub-control you want over the textures I guess. I am most familiar with the Max system and find it very simple and reliable, but it does lack the texture list function you are talking about. I am not sure how necessary it is though.

At it's simplest I would be fine with just being able to copy/paste or drag a texture from any given slot to another and be given the choice "instance or copy?" In Max, instanced textures are identified by an icon in the Material Editor, but they could be tagged any number of ways. If you wish to isolate a texture to make it different from the rest you can choose "make unique" and it maintains it's settings but is no longer linked to the others.

Now, to enhance my own control I tend to put bitmaps inside another 'container' shader (Output, Colour correction, etc.) and instance the *bitmap* but not the containing shader. This way I can ajdust brightness/output levels etc. on a per map slot basis, but maintain the advantage of instancing all other bitmap parameters. This is my favourite approach by far, the only thing it lacks is really strong image manipulation tools (besides the obvious flaw that it doesn't work with Maxwell ) but it gives me a really efficient, simple, and more error-proof workflow so I really like it.

I can see many advantages to creating a Maxwell bitmap 'container' shader that covers these things off, but I think it unlikely NL will have the time/interest. It would be a great toolset though.

[Mihai]

Jeremy, I think of Softimage reading that, where you can either have a texture created from a 'source' or a 'clip'. You can create a clip from a source texture which is that same texture but can have different attributes. So in a way it's 'instancing' a texture. But I think what would be useful in the case of Maxwell is a way to have global per material settings for tiling. What other 'texture parameters' do you want linked between materials?

[simmsimaging]

Jeremy, I think of Softimage reading that, where you can either have a texture created from a 'source' or a 'clip'. You can create a clip from a source texture which is that same texture but can have different attributes. So in a way it's 'instancing' a texture. But I think what would be useful in the case of Maxwell is a way to have global per material settings for tiling. What other 'texture parameters' do you want linked between materials?

Hey Mihai
Global tiling would be far less useful as it is very common to use multiple bitmaps and not all would be tiled the same. It really needs to be per map. Other parameters needed would really include all of them. Tiling, offsets, clipping, inverted.... All are necessary unless you have two levels of instantiation like I talked about.

[JDHill]

Mihai -- to speak accurately, they wouldn't really be linked between materials, but rather, maps in multiple materials would link to common textures. Basically, just take what you see in the current texture editor, separate it out into its own concept, and link instances of that concept to multiple maps, in multiple materials, just as materials are currently linked to multiple objects in the scene. Add to that the ability to override individual parameters (tile, etc) within a given map, and that is the whole picture. Trying to say, for example, "tile will be a linked parameter, but invert will not" (which is what I infer from your question) would complicate, rather than simplify the model. Furthermore, most of the texture parameters need to be modified globally in many cases; tile, offset, real scale, invert, sat/con/bri, pretty much everything. I've seen alot of scenes where, say, a particular file is used as a mask image in several similar materials -- if you decide you want the map inverted, you probably want it inverted every place that it's used.

Also, just to mention, I don't follow you guys too much when you reference 3dsmax or softimage, since I've never used those apps. Rhino has been trying to implement something along the lines of 'instances' for materials & textures, and imho, it's a bit of a conceptual mess -- it introduces the concept, but doesn't have a cohesive UI story for it, so it's not obvious (to me, maybe it's natural for somebody else) what you're actually working with at any particular moment. Brett's mention of 'make unique' leads me to think the 3dsmax system might be similar. Node-based systems (not sure, but I get the idea that's what you have in softimage) can be powerful, but my perception is that lots of users find them to be too abstract and intimidating. Not only that, but anything we come up with needs to be able to be compatible with implementation in a ton of plugins; list-based, referenced textures are entirely doable. Technically, what I am talking about here would be both forward and backward compatible with Maxwell's existing system.

It is something that I could implement in plugins, translating to the current non-linked system at export; the problem with doing that, though, is that if an incompatible competing system were then later implemented in Maxwell itself, it could be very difficult to resolve the two.

[simmsimaging]

Maybe you can get some input from Mihnea and the guys on the Max plugin side. They have managed to make it work with the existing system in Max and Maxwell. My guess is that compatibility is maintained by converting all the maps to copies on export to Maxwell, but at least the idea is there. It is not inherently node based in Max, but the node based editor does make it *vastly* easier to organize complex materials, and is very handy for setting up instancing and common parameters (e.g wiring bump value of two different materials together).

In any case, I would disagree with a few things you mentioned JD. Linking/instancing *some* parameters can be extremely useful, but the most common instancing wouldn't need that. However, I think as much as it might be common to have the same image used as a weight map/mask and thus use global values for things, it is also very common to use the same map with very different adjustments to things like clipping etc when used in other slots (roughness, bump, etc). It would be much more useful to be able to break out *all* bitmap variables as one set of instance-able parameters, and the core bitmap itself as an instance-able item.

One thing I would like to point out though: please be careful of approaching it from the standpoint of what makes sense in terms of programming. A lot of stuff (particularly UI) tends to be done that way in software and it is often not the best approach from a user standpoint. I think a function like this needs to be driven by the user requirements, what makes sense in a common workflow, rather than going at it from the other end.

I might be misreading your priority on it, so just flagging it as a point of consideration.


/b

[Polyxo]

I very much like the elegant but optional and on the Fly linking of Channel-Textures as it exists inside Maxwell for Rhino.
So one can change several Tiling and Colour-Override values at the same time but one does not have to.
I find this so much better than in Mxed so that I have a hard time using Maxwell outside of Rhino.

Two things might make this even better:
1) A "Make Unique" flag for single maps. It would just ignore all synchronizing Modifier-Key Actions.
One should clearly see that Unique status (coloured map outline?), it might even help if one could see at Layer-Level already that it contains such
"non driven and non driving" maps. It would be cool if one did not have to search for the single map which makes a material look odd.

2) A simple manual Copy-Paste Parameters Action (e.g Ctrl+Shift+C/V). With a channel-texture selected in its slot
it would copy/paste everything but the Image itself.

Apart from that I very much like the plan of having a list of already active Textures available.
I know implementations of this feature from Blender as well as from PMG Messiah and could provide Screenshots if desired.
It would be cool if one could pick from the list while again having Modifier-Key Operations at hand. Load Image with Parameters
as used in other Slots, load without Parameters (gets flagged Unique) etc.

[eric nixon]

A simple manual Copy-Paste Parameters Action (e.g Ctrl+Shift+C/V).

That would do it! copy all tiling and offsets in one convenient click. Thats a useful button (or keyboard shortcut) that wont mess anything else up.

If you want all the params inc contrast etc. then just drag and drop the tag as usual.

Make unique has potential problems if you think about the same map being used in two sets of params within one material and what happens when you un-click 'make unique'

Second point which might help Primus out, Occasionally it would be helpful to manipulate sets of maps, in a material, interactively in fire. but in that case we can just use channels instead with certain sets of maps assigned to a channel. This is easy to do in the cinema plug, I know that much

I see Brett is master of copy and paste, this thread certainly has a mixed up timeline, maybe you should do another edit?

[Polyxo]

In any case, I would disagree with a few things you mentioned JD. Linking/instancing *some* parameters can be extremely useful, but the most common instancing wouldn't need that. However, I think as much as it might be common to have the same image used as a weight map/mask and thus use global values for things, it is also very common to use the same map with very different adjustments to things like clipping etc when used in other slots (roughness, bump, etc). It would be much more useful to be able to break out *all* bitmap variables as one set of instance-able parameters, and the core bitmap itself as an instance-able item.
/b

Doesn't this depend tremendously on the way the Textures were made?
In case a stack of textures was created explicidly for a single piece of Geometry (UV-Set) inside of Zbrush or 3DCoat or any other Painting-App I could not imagine how one would use any
other tiling Value as 1. It is hardcoded into the maps so to say. Here one only needs to set Spinner-Values. When one freely creates mxm's from generic tilable Textures that may be quite a different story though.

[simmsimaging]

In any case, I would disagree with a few things you mentioned JD. Linking/instancing *some* parameters can be extremely useful, but the most common instancing wouldn't need that. However, I think as much as it might be common to have the same image used as a weight map/mask and thus use global values for things, it is also very common to use the same map with very different adjustments to things like clipping etc when used in other slots (roughness, bump, etc). It would be much more useful to be able to break out *all* bitmap variables as one set of instance-able parameters, and the core bitmap itself as an instance-able item.
/b

Doesn't this depend tremendously on the way the Textures were made?
In case a stack of textures was created explicidly for a single piece of Geometry (UV-Set) inside of Zbrush or 3DCoat or any other Painting-App I could not imagine how one would use any
other tiling Value as 1. It is hardcoded into the maps so to say. Here one only needs to set Spinner-Values. When one freely creates mxm's from generic tilable Textures that may be quite a different story though.

Exactly. It is very common to use tiling textures - in fact I use them whenever I can to avoid custom painting every object. I would actually be willing to be that the vast majority of textures used in CG are tileable, at least as a baseline, and then customized on top as needed.

/b

[simmsimaging]

:I see Brett is master of copy and paste, this thread certainly has a mixed up timeline, maybe you should do another edit?

I have no idea what you are talking about. I have yet to edit any posts or copy/paste anything. I use the "quote" function built into the reply system. You are finding that confusing somehow?

[Polyxo]

Exactly. It is very common to use tiling textures - in fact I use them whenever I can to avoid custom painting every object. I would actually be willing to be that the vast majority of textures used in CG are tileable, at least as a baseline, and then customized on top as needed.

I understand.
Still I would say that individually painted textures are getting more and more common - just considering how many Apps nowadays offer 3D-painting...
Also I find this sort of Texture work more or less the only useful method on Nurbs for Industrial-Design Work as one here has no full UV-based control
as on typical Mesh-Geometry.