[Kabe]

After I re-export the scene to Maxwell it must know to update the objects, but keep the materials I have already adjusted.

Wrong

Yes. It's wrong - I never said that.

You create two IDENTICAL material libraries in both HOST and MAXWELL libraries and a CORRESPONDANCE list. Thats all

I cannot find any mess.

There's no need to duplicate libraries. If you would like to have a correspondance list, just assign Maxwell materials to Host materials and you are set.

This apporach is quite limiited though, because the relation of Host and Maxwell materials might not be 1:1 or 1:n. If you would like to assign different Maxwell materials to the same Host material, then you are lost. So you have to start duplicating Host materials to assign Maxwell materials.

Kabe, i dont think that NL could create a live connection for all supported applications in another way. Propably for 2-3 apps but not more

They don't need to. All they could provide - and even this is more a convenience feature - would be a way to call M~R in the background to provide a preview pict for materials. It's up to the plugin coders to use that method, and they don't need to to get functional.

Kabe

[Mihai]

1) You create a scene, go to maxwell and assign to each dummy material the real one. And now you edit the scene in the host. If there is not a correspondance list then you have to do the assignment once again.
With the list there is not need. The program will know dummy_1 -> material_1 and so on

Well, we are really talking about almost the same thing, I prefer though to call it Scene Material Library. Once you have exported the scene into Maxwell, Maxwell can keep track of which materials are applied to which object so it creates itself this material list. For example I had mat1 in host app, export to Maxwell, mat1 becomes a Maxwell material. If I go back to my scene and add another object and assign to it mat1, when I export the scene back to Maxwell, that object will also get assigned to it the Maxwell mat1.

2) You have an animation. Then you dont have to do the assignment for every single frame. You can do it once using the list.

Here again a scene material file would be used. Possible workflow: Export first frame>assign materials>Maxwell creates material library for this scene. For subsequent frames exported from the host plugin, there should be an option to choose what material library this sequence should use.

3) Another very important one.
If you are consistetn in material naming then you will have to do the correspondance list only ONCE and then just edit it and enchanhe it.
You do scene_1 in host app and then scene_2 if you use the same material names then you can skip the assignment part.

The way I thought it would work is: First you have the individual Maxwell material files (these can be simple text files perhaps). Then you have a scene material file, could certainly be a textfile, where you just simply specify which individual mat files belong in this scene.

So we are talking about the same thing, but I'm saying there is no need for the user to write themselves these lists, it should be handled by Maxwell, it should just write: individual material files, scene material file.

Ofcourse if you wanted to you could always re-use or edit one of those scene material files.

[Kabe]

Me thinks you are both talking about the same workflow. So lets make it a bit easier :

1. You modell a cube (a room for example)
2. You click on the lower polygon and give the materialname "floor"
3. You click on the top polygon and name it "ceiling"
4. You click on the side polygones and give the material name "walls"

So now you have an object with three different materials, thats all you export to Maxwell. Now in Maxwell you get a material list with three names, there you can assign you're materials as usual.

That is stone age. Manual bookkeeping. Hacking. It can break at so many places it doesn't hold any water.

There is no process security in this, there is no way to ensure that this works reliable, not to talk about groups of people working under pressure. It's plain stupid to do stuff like this in a production workflow.

The workflow I propose is *much* safer:

1. Prebuild NMM-libraries in the Maxwell Material Designer. here you have full access to specific Maxwell settings that are relevant only for Maxwell.

2. Assign NMMs in the host app (this could be by assigning to objects or to Host materials, but this is a plugin implementation detail of lesser importance). If you need to you can also assign maps and tweak some settings like color or bump.
If this creates a new variant of an existing material, you might save out it to the library.

3. Export to MXI to render

What's wrong with that?

Kabe

[Mihai]

Kabe, I think there are some serious misunderstandings here...I won't quote your whole post because you're confusing the hell out of me.

When I say assign a texture, I do NOT mean assign a texture to a certain object, I am saying you already have the material, ALL you have to do is pick a bitmap for the bump map in that material for example.

You do NOT have to select objects in the Maxwell GUI, or material editor, because you do NOT need to assign materials there. You assign the MATERIAL TYPE in your host app.

Lets take a simple example shall we?

1. I model a cube
2. I assign cubic UV's to that cube
3. I adjust the UV's of that cube
4. I assign the MATERIAL TYPE 'Maxwell Plastic' from a dropdown menu.
5. I give this material the name 'mat1'.

6. I export the scene into Maxwell.
7 Maxwell reads the file exported by the plugin, reads that mat1 is applied to this cube and sees it is a Maxwell Plastic material.
8. Maxwell automatically creates a default plastic material with the name 'mat1'.

9. In this Maxwell material I can assign bitmaps, change tiling, change every advanced and non advanced aspect of this material.
10. Render

11. Maxwell has also created a separate mxm (Maxwell material file) and a separate scene material library file for my scene.

12. I need to add a few verts to this cube and also add a second cube.

13. I go back to my modeling app, make the changes, apply a Maxwell Dielectric material type to the second cube, call it 'glass1'.

14. For convenience sake, I now specify in the export plugin, before exporting the scene, which scene library file this scene should use.

15. I export the scene to Maxwell, it sees that I have specified a scene library files, so it assigns the 'mat1' material to my old cube, while at the same time automatically creating a default glass material for the second cube.

16. Re-render


So in Maxwell there is no object selection, every material is already assigned to the objects.

If I have missed something please let me know because I don't see what's wrong with this setup.

Now I need to change batteries on my keyboard

[Frances]

Mihai, I don't think that exporting geometry back to the host app is a good idea. There is no way I would expect M~W to have to make a round trip with Rhino nurbs or complicated Max modifier stacks intact. Especially since all M~W does is get Rhino's render mesh or Max's viewport mesh and export that. What you would end up with in your model is "dumb" meshes.

I can see the value of being able to perform material tweeks in the GUI and then update a library that is shared by M~W and the host app. I would prefer that the mat editor be integrated into the host application as well as being accessible by the GUI.

[Mihai]

Kabe, reading your last post, it seems we are also talking about sort of the same thing

What we are arguing about really is were to specify these Maxwell material files. I thought you ment you wanted to edit them in the host app, via the plugins.

Frances, you wouldn't be exporting anything back FROM Maxwell to your host app. If you update an object, you just re-export it to Maxwell, it knows what materials belong to what object via a scene material file it created with the first export.

[Kabe]

If i should define material curves for sss how would a native app handle that.

[you propably wont answer as you did for the previous questions, but i cannot understand why]

The Host app or the plugin does not have to handle those Maxwell Material Curves. All it has to do is to store them.

Let's say you design a NMM, it has 3 curves, 2 options that are useful for Maxwell only, and 3 maps and a color for the user options. You save that to the library. The plugin sees a new NMM, which has 3 maps, a color, and a block of "black box data" that it just has to keep. The plugin is just the postman here, and neither the texturing nor the export plugin need to know anything about the meaning of these data.

The plugin doesn't even have to know what kind of data the future might bring, as long as it can handle the user options, and treats everything else as "black box" data.
This would even allow to introduce new "user option types" without the need to rewrite every single plugin. The new options would not show in plugin that don't support them, but their data would be transmitted nonetheless. This way you could introduce new material types without breaking the existing plugins. As a bonus, you could get upward compatibility.

Kabe

[Frances]

Hi Mihai,

Oops. But I don't see an advantage to this workflow.

I'm too tired to figure it out right now. So before I juxtapose any more verbs, I'll quit while I'm behind.

[Kabe]

can i answer, cause you seem to ignore all my posts?.

buffos, don't be rude. I usually think before and while writing. It takes time. and I reserve the right to answer to the posts I'm interested in, not to the one who shouts loudest.
If you would like to get answers, write postings with new and refreshing ideas. Don't try to reiterate yourself. Don't try to look stupid. You might take that as a general piece of advice

Cheers

Kabe

[Mihai]

and 3 maps and a color for the user options.

I wonder though since Maxwell works on spectral info than perhaps the advanced material editor will not work using RGB, or only RGB.

It seems to me it's material editor will still need options to assign even colors, so the only things left to do in the host app would be to assign textures, change tiling, perhaps bumpmap strength, and that's about it.

But, since these material files will also need to have 'other' info, then likely they won't be text files, which leaves the option for the material editor to be able to read these files and let you change tiling, texture assignment and so on right? OR, to change bumpmap strength, or texture you would need to change it in your host app, then re-export the scene, or materials? Not too practical I think.

So....we are sort of back where we started...why take more time writing these things in the plugins when, as I see it, Maxwell's advanced material editor/GUI will have to have their functionality anyway. It's double work...

[giacob]

i am not am expert at all.. but as a user i'd prefer one of this options:
1-in the application just making only the geometry ... exporting in maxwell standalone and then having there material editor , applying material, uvw etc ;
2- making geometry, material assignement, uwmap in the applications as it is now, but with material beeing saw in the editor.This way seems to me more easy to make animation ( if u want to animate materials how can u do with option one)

Even if prefer option 2, both are good to me .. what i would dislike very much would be a mixing up of both such as applying the materials in the apllication an then adjusting parameter in maxwell... that would be time wasting and confusing to me

[Kabe]

I wonder though since Maxwell works on spectral info than perhaps the advanced material editor will not work using RGB, or only RGB.
It seems to me it's material editor will still need options to assign even colors

It can and probably will, that's exactly why such a Material editor is needed. Color assignment could take place with a continuos color wheel.

However, this doesn't exclude a user setting which uses an rgb color!

But, since these material files will also need to have 'other' info, then likely they won't be text files, which leaves the option for the material editor to be able to read these files and let you change tiling, texture assignment and so on right?

The file format must be documented, that's all. It really doesn't matter much if it's a text file or not. Given the small amount of data you could be saved as XML though to have them in a text format...

OR, to change bumpmap strength, or texture you would need to change it in your host app, then re-export the scene, or materials? Not too practical I think.

Yes. Exactly what the average user expects in a linear workflow I think.

So....we are sort of back where we started...why take more time writing these things in the plugins when, as I see it, Maxwell's advanced material editor/GUI will have to have their functionality anyway. It's double work...

Because if you need to texture in the host app - and I think we agree on this, right? - then you need to support basic settings like assigning maps. So why stop then when you halfway there instead of providing the user as much control as needed?
Besides: If properly implemented, then you write this stuff *once*. IMO there is no point in limiting yourself to just textures, instead of going the extra Meter to also support booleans, floats and colors.

Good night!

Kabe

[Kabe]

Even if prefer option 2, both are good to me .. what i would dislike very much would be a mixing up of both such as applying the materials in the apllication an then adjusting parameter in maxwell... that would be time wasting and confusing to me

No user should be required to design NMMs on their own. There probably will be advanced parameters in Maxwell many users won't touch anyway. The average Joe will stick with the library, and make his adjustments, eventually save out a variant... end of story.
He might get additionally libraries somewhere, but there's not need to mess with designing your very own. But if you would like to do this, then it must happen in a seperate application, which is what I've called the Maxwell Material Designer.

The problem of the alternatives are this:

You can't have full access to all Maxwell parameters without writing new stuff for each plugin when you release a new material type. So this won't happen, it's far from flexible enough.

Texturing in Maxwell could not compete by any standard with established workflows, and it has to be redone when the scene changes in the host application. Doesn't sound good to me.

Kabe

[Mihai]

So....we are sort of back where we started...why take more time writing these things in the plugins when, as I see it, Maxwell's advanced material editor/GUI will have to have their functionality anyway. It's double work...

Because if you need to texture in the host app - and I think we agree on this, right? - then you need to support basic settings like assigning maps.
Kabe

Well, if you want to write those things into the plugins as well, then be my guest. But I don't want that to mean that the Maxwell GUI with it's material editor will not have options to assign textures (note I mean assign textures to different material slots, NOT assign materials to objects), change tiling, change bumpmap settings and so on.

Because otherwise I would have to have the host app open all the time alongside Maxwell just so I will be able to change the tiling on one material from 2 to 3?

If I'm already in Maxwell, making changes, adjusting light intensities and so on, why not just have a setting there to take care of these things, instead of going back to the host app, change one number, export again. Every time.

It makes much more sense to be able to change these things inside the Maxwell GUI where I can instantly see changes. Remember they mentioned they will have an almost realtime preview option.

Texturing in Maxwell could not compete by any standard with established workflows, and it has to be redone when the scene changes in the host application. Doesn't sound good to me.

What do you mean by 'texturing in Maxwell'? All I'm talking about is specifying bitmaps for different slots. The materials would already be assigned inside your host app....the uv's will already be made in your host app.....

[Kabe]

Well, if you want to write those things into the plugins as well, then be my guest. But I don't want that to mean that the Maxwell GUI with it's material editor will not have options to assign textures (note I mean assign textures to different material slots, NOT assign materials to objects), change tiling, change bumpmap settings and so on.
It makes much more sense to be able to change these things inside the Maxwell GUI where I can instantly see changes. Remember they mentioned they will have an almost realtime preview option.

I agree that this would be nice. Changing a material from the list could be done relatively easily.
Tiling however, is much more complicated coz such a thing requires access to the scene's object tree: Tiling is a parameter of the object or the UV Map, not of the Material itself!

So, I really go to sleep now.

Kabe