Maxwell Render

Agree, I don't see such functionalities not as bloat, too; especially since these types of basic manipulations are straightforward to implement programmatically and have been around in 3D softwares since 1991(!). As you say, it's all about a hassle-free workflow. If only one could rotate a map in Maxwell Studio or change the colour balance - and have visual feedback in the material editor, that'd be something. And then, being able to propagate to the other maps within the MXM and to other MXMs...

An example to illustrate what I mean regarding the "prehistoric" Alias material and texture editor that has some simple but extremely useful capabilities built in

Change tiling, offset, RGB values, blur


Copy selected parameters from one material to selected other materials


See all changes interactively in the texture editor and the material lister


So, no need for "geeky clickmania" at all; in fact - much less clicking involved compared to using an external image manipulation software such as Photoshop/Gimp ;)

Hi Brett, let me know if this helps at all:

_________________
Next Limit Team

Hi JD, if I may...
I would really like to get access such a Scene-Library!
Personally however I rather would like to see such as an extension to the File-Loader, instead of having two separate tools and locations available.
So one could check for a certain file and grab it from the pool of referenced images. In case however that the required bitmap
is not yet in use inside the running session I would consider more straightforward to load load the File directly from the Library you are showing
on the left side of your illustration.

Further - I like the idea (and have proposed it myself) of indicator-colours when overriding default values of a certain map.
However - I think it was not required to display such colours when looking at directly evident values - such as Tiling Settings.

To me it is a bit hard to comment on Mxed as I am very used to the Rhino-Plugin-Interface which exposes Texture-Tiling at Top-Level
what I consider greatly better. So please take this with a grain of salt... Generally I think any sort of Override indicators were only required
when the override takes place at least one hierarchy-level below the level one currently looks at.

So - transferred to the Rhino-Plugin I would like to get an indication that e.g. the Saturation of a Map was edited on BSDF-Level.
But I would not really need it when looking at the Colour-Override Popup itself. Here one can see the Slider-Positions so indicators were redundant.
One in case of override might consider to colour the Reset-Icons you give us inside the Rhino-Plugin (and maybe some others of yours).
But I'm not sure about a separate indicator-dot.

Sure, this is by no means meant to represent a complete picture. Of course, the Texture List window would provide functions for creating new Texture definitions directly. In case it is not clear, both Texture Editor pictures above represent the same UI, working in its two modes: editing a Texture definition, and editing a specific map.


First, there are only two levels here: Texture definitions, and maps which reference them. Indicators are mandatory in the referencing map, so that you can unset an override for a parameter, thereby allowing it to once again use the value defined in the definition. They could also be used at the definition level, to show which of the definition's parameters are eventually overridden in at least one map, but I don't personally think that is worth the added complication. The way to think of it is: Texture definitions, shown in the Textures list, are interactive templates for maps; individual maps use a certain template, and override individual parameters where desired.


I am concerned here only with envisioning a system in terms of Maxwell itself -- it would then need to be integrated with specific plugins like Rhino, where it might or might not work similarly. In some cases, it wouldn't appear this way at all, since the host app may provide a system which is more powerful, or incompatible.

_________________
Next Limit Team

For sure, but even then you are dealing with UV's (because you don't have PTEX in Maxwell) so there are many places where I can and do still blend in tiling maps for some things (seams are not always an issue so a quick box map or planar map is useful for some things). Anyway, instancing is still useful in that workflow, maybe just a bit less so in terms of the texmaps, but can still be really useful on other levels. For example: being able to instance BSDF layers, or entire material layers between different MXM's (i.e creating multiple variations of otherwise highly consistent materials). That too is something I use a lot.

b

_________________
Brett Simms
http://www.heavyartillery.com

Please comment;

_________________
Materials, Arch-viz, C4D Dynamics

Hey JD

I think we are more or less on the same page. However, I'm coming at it from the standpoint of what makes the most sense as a user, and I think you are coming at it from the standpoint of what makes the most sense from the existing Maxwell architecture angle, and for obvious reasons.

Here's a conceptual diagram of what I think is needed. I have kept it intentionally simple to show the connectivity, not as an example of how it would be useful in particular.

http://www.evernote.com/shard/s2/sh/5ccbda6e-a63a-4060-b38e-7273fc7c7097/04bb282b7b6fe82566d4cea9eb84f4ac

At the texture level, my suggestion here would entail breaking the current texture editor into a two part container instead of having the two sections as one. The precise UI arrangement is not considered here, it's more about nailing down the functionality at this phase (in my mind).

The basic projection tools are what need to be instanced probably 95% of the time. The image properties are where you would be adding unique per-slot variations in a material, or across several materials. My diagram indicates how one map would be instanced in one case between two different BSDFs, and one is used uniquely in a 3rd BSDF.

Ideally the instancing system would be one or two levels higher as well, so that the BSDF layers could be instanced within and between materials as well, but that is not shown here.

Conceptually we would be looking at breaking the texture editor into two components, but functionally this would not be ideal. In order to avoid breaking the existing system of Maxwell, and to appease people like Eric who are apparently against the idea of instancing on religious grounds (;)) my suggestion would be to leave the texture editor alone, and add a new texture editor container node that you would *nest* the existing texture into. It would basically have the exact same bitmap parameters and image property parameters. You could then nest a 'normal' texture into one of those "containers" as an instance and it's bitmap and image properties would override any/all of the root texture editor values. That way all parameters could be instanced *except* the ones you override in the container settings. That container could then be instanced too, if the system goes all the way up to the layer level in the materials.

I strongly encourage taking it that far too. Instancing of BSDF layers would be almost as important as bitmap instancing IMO.

UI would need some consideration (flagging as an instance vs unique etc) but you are on a good track with the orange/green dot thing - and I think that would be just a matter of figuring out what is the simplest/clearest once the core functionality was decided.

/b

_________________
Brett Simms
http://www.heavyartillery.com

Hey Eric, I think you may still be missing the point. One-time setup is only a small component of the instancing workflow. The time savings come from updating/adapting/tweaking that goes into developing complex materials. If you only ever set the values/parameters once then instancing is effectively identical to copy/paste and the button suggestion above would work, but that is easily done now by drag/drop. However every time you make a change while refining instancing becomes more and more useful.

I fail to understand the concern over messing things up. Instancing would not be a default, and you could basically act as if it wasn't even there and nothing would have to change for you.

"make unique" has zero potential problems, *except* for the instancing workflow. If you click that button (as it works in Max, for example) it doesn't precisely nothing except turn of the link between parameters. Nothing will change in your material until you go in and edit the parameters of one of the (former) instances. At that point you begin to create divergent versions again, nothing more.

It really doesn't have to be a conflict with your approach at all - I seriously think you just misunderstand how it would be used.

/b

_________________
Brett Simms
http://www.heavyartillery.com

Brett, i don't know if that is just me, but i can't see the images you attatched in the previous posting.

_________________
workstation: EVGA SR-2 / dual x5650@3.5Ghz / quadro 4000

Sorry - all of a sudden Evernote doesn't seem to allow image linking anymore. Edited to show the direct link, but I'll have to start posting images another way to get them to show inline.

/b

_________________
Brett Simms
http://www.heavyartillery.com

I understand your suggestion, but my opinion is that such a level of indirection is untenable in the absence of a node-based interface. Even in the shallower 2-level system I suggest, the texture UI is completely switching context; at least it only has two modes -- with further nesting of more panels inside of those, it would quickly become confusing as to what was related to what, and how you get from here to there. It is not that I am against adopting a model such as the one you suggest, but there we begin talking more or less about rewriting Maxwell, whereas here, I am only talking about implementing texture instancing, which I feel is something that is lacking.

And I think it would be safe to guess you'll agree that in reality, even the flatter system I suggest would be pretty much revolutionary in terms of improving the texture workflow in Maxwell. Compared to the current workflow, the two are not even in the same universe, imho.

And for what it's worth, since you allude to my being a developer, this is what I would've proposed here whether I was coding or not. There is the cost-benefit to think of -- resources being finite, one thing necessarily takes from another. So with that in mind, I would suggest what I have, simply because I think it covers the greatest amount of ground, while not making its actual implementation too unlikely. Were the topic a clean-sheet rewrite, suffice to say, I would have very different suggestions than this one.

_________________
Next Limit Team

yeah, it is a bad habit some host are introducing..
but you can get around copying the DL link from your browser.

*edit:

really strange, it works once then it remains blocked.
sorry, nevermind

_________________
workstation: EVGA SR-2 / dual x5650@3.5Ghz / quadro 4000

Here's a link that should work. As a note, I did copy the DL link from the browswer - that's been how I have used it to now. Still no joy apparently. Anyway, I can host them myself, it's just more clicks that way - and we've established how I feel about too many clicks

_________________
Brett Simms
http://www.heavyartillery.com

It's been very tenable in Max for years before there was a node based interface. It works just fine without nodes, unless by that you mean something more 'behind the scenes' and not just the UI?

I would agree that some level of instancing is better than none, for sure, but more robust instancing is an order of magnitude more useful. However, in terms of cost/benefit it's something that would be almost impossible to quantify in reality. My guess is that the higher end users that are doing more complex/realistic materials will be all for it, and many others would not care in the least. In that it will be like a great many other features and functions though.

It's not to say that I don't recognize a cost/benefit scenario is important, and core modifications to Maxwell are not to be taken lightly, but it is a mistake, IMO, to *start* with the problems and then generate a solution. That easily leads to cul-de-sac solutions that are more determined by past necessity than current necessity (just look at a good chunk of what makes up 3DSMax). The kind of programs that function the best, and that people respond to the best, are the ones that most efficiently solve the day to day problems that people have, and with the easiest to learn UI - on that we can both agree I'm sure. So in this case, the functionality and it's relative worth should take precedence over the implementation, at least until it's clearer how beneficial it might be.

I'm not saying you don't see that, or that we wouldn't arrive that the same place, but both our perspectives introduce bias in how we approach the issue. My bias is the one that favours the consumer though, and I think it's good for business to give that a serious look before going with what is convenient/least costly up-front.

_________________
Brett Simms
http://www.heavyartillery.com