[Mihai]

Kabe, are you familiar with Mental Ray?

"In addition to built-in shaders, user-defined shaders written in standard C can be precompiled and linked at runtime, or can be both compiled and linked at runtime. User-defined shaders can be used in place of any built-in shader, redefining materials, textures, lights, environments, volumes, displacements etc.

mental ray can link in user-defined shaders in either object, source, or dynamic shared object (DSO) form.

Every user-defined shader must be declared before it can be used. (see shader declaration) A declaration is a statement that names the shader, and lists the name and type of all its parameters. Declarations may appear in the .mi file, but are typically stored in an external file included at run time."

Are you telling me that this system used by Mental Ray for years and used by hundreds of production houses is one of those CBI™ things you keep mentioning?

I think you are at fault to first of all think from a programmers point of view. Before any code is written, we have to decide the exact workflow, the best and most convenient possible workflow.

It's when you keep adapting the user to the software that later you are forced to make more and more hacks, because the user demands further functionality, which unfortunately you have excluded from the beginning. After 5-6 revisions, you come to the conclusion that it's time for a complete rewrite of the system. It's not a good start IMO.

Lets first discuss how we would like this connection to work.

Personally I think there's little point in discussing connections without discussing how a 'live' link is to be kept between host app and Maxwell, to avoid retexturing everything on the slightest change. If we can't have this, than it's absolutely no use talking about a Maxwell connection, because there would be no workflow at all.

We agree that all material params cannot be set in the host plugins right?

So, we have to set them in some sort of Maxwell material editor. How will those materials be stored, how can they be linked to the scene so you don't have to re-texture, how can these materials be re-used in other scenes in the most efficient and fastest way?

[Kabe]

the export plugin will export what it allread does now.
Geometry, UV, and materials (although dummy ones as they will be changed with native once.)

Yes all that is needed is an obj->mxs converter... EXCACLY
I am talking about an alternative way for all the apps that will never have a maxwell plugin.

The problem is: This isn't an alternative for all the apps out there.
Actually it doesn't help all CAD users at all.

See Hugh's problem: He uses AutoCAD. I'm not shure if he even can create Wavefront OBJ, but I'm relatively shure that AutoCAD doesn't create UV coords. So, these users are still without a solution.

Kabe

[Kabe]

Declarations may appear in the .mi file, but are typically stored in an external file includes at run time." [/i]

Are you telling me that this system used by Mental Ray for years and used by hundreds of production houses is one of those CBI™ things you keep mentioning?

No. Includes are fine and used in a lot of contexts. However, not many people mess around with included in a text editor.

I think you are at fault to first of all think from a programmers point of view. Before any code is written, we have to decide the exact workflow, the best and most convenient possible workflow.

I don't think this from a programmer's viewpoint. However, it's pointless to design the best and most convenient workflow if in the end you can't deliver.

It's when you keep adapting the user to the software that later you are forced to make more and more hacks, because the user demands further functionality, which unfortunately you have excluded from the beginning. After 5-6 revisions, you come to the conclusion that it's time for a complete rewrite of the system.

Do you really think that allowing material includes would force a rewrite? Don't be silly, this is really a minor detail. Claim them optionally and you can create them whenever you like without breaking anything.

I have nothing against includes, nothing effective at least

The problem with includes is: They don't solve the problem:

If you would like to exchange materials, you could do that much more convenient in Maxwell as well.

And if you would like to feedback those changes, then includes don't save the problem of rematching Maxwell objects to host objects. THAT is the problem, not the data storage.

It doesn't matter much if this is stored as binary or text, or inside the MXS or as in include. All this are implementation details with not much meaning. I really don't care.

How would you like to feedback the changes you made to the host app - that is the question - and you don't have an viable answer for it yet.

Personally I think there's little point in discussing connections without discussing how a 'live' link is to be kept between host app and Maxwell, to avoid retexturing everything on the slightest change. If we can't have this, than it's absolutely no use talking about a Maxwell connection, because there would be no workflow at all.

Workflows, as Pipelines have a direction. Feedbacks in workflows are hard to control, hard to implement and easy to break. IMO texturing should happen in the host app.

We agree that all material params cannot be set in the host plugins right?

So, we have to set them in some sort of Maxwell material editor. How will those materials be stored, how can they be linked to the scene so you don't have to re-texture, how can these materials be re-used in other scenes in the most efficient and fastest way?

As I explained earlier: Design NMM libraries. Assign NMMs in the host to your objects using the plugin, allow editing of user data (and optionally save out NMM variants back to the library).
Let the host do the data storage. The host export/render plugin exports that data to MXS (maybe writes the Materials to an include, I really don't care), render.

If someone would like to write "Mihais feedback plugin" to allow your proposed workflow, then he can. I rather would hit myself with a blunt object

Kabe

[Tyrone Marshall]

I agree I see no reason for this as long as what you change in the advanced material editor can be exported through translation and picked up by the host application in some import/export (description format) into the material in the host application so that your updates are made active. I have seen plugins for C4D that allow for you import/export specific information that pertains to the plugin so that you can *retrieve* certain data sets of information back into C4D and back into the plugin that originated from within the plugin through export- so this is very possible.

What plugin exactly do you think of?

I think it would be pretty complicated with Maxwell, after all, this is a huge application and it should and will be optimized to be a killer renderer, not a "eierlegende Wollmilchsau".

I strongly suggest though that any plugins should have the option to specify a scene materials library file. This file will just be a simple text file to specify which object gets which material. This way you can very quickly set up a scene and have effective use of any maxwell materials you might have set up in the past.

I doubt that this concept will carry you far in a production environment. Editing text files destroy referential integrity, it's a CBI™ you have to avoid.
I like the idea of having a material list in an MXS file though, which you might export or exchange by others. However, this will break the pipeline, so I'm not too fond of it.

Kabe

I wrote the first quote, Mihai wrote the second.

The plugin I am thinking of that has this nice feature is SuperGraphx (supershapes) for C4D by genicap. I can make my shapes, and save them out from within the plugin in special description language separate from C4D. Very nice, as I can now create my own little library of supershapes.

PS: Is your avatar a WIP? I have been looking at it lately (hard to miss this huge eye starring at you!) But it seems to be much more realistic lately. What is going on?!?!? It is just strange!

[Kabe]

The plugin I am thinking of that has this nice feature is SuperGraphx (supershapes) for C4D by genicap. I can make my shapes, and save them out from within the plugin in special description language separate from C4D. Very nice, as I can now create my own little library of supershapes.

Ehm, this is saving out data from the plugin, and probably reading them in. However, this is different to attach data to a scene graph, and later remerge it. So this is not an example for a functioning feedback loop.

PS: Is your avatar a WIP? I have been looking at it lately (hard to miss this huge eye starring at you!) But it seems to be much more realistic lately. What is going on?!?!? It is just strange!

It is, indeed. The older version was rendered in Cinema, the new version was rendered in Maxwell...


Cheers

Kabe

[Mihai]

As I explained earlier: Design NMM libraries. Assign NMMs in the host to your objects using the plugin, allow editing of user data (and optionally save out NMM variants back to the library).
Let the host do the data storage. The host export/render plugin exports that data to MXS (maybe writes the Materials to an include, I really don't care), render.

The only thing I would do different from your explanation is like I said, include in this plugin a general file that tells the plugin exactly which material to assign to which object.

You may not find it terribly important, but it will end up saving lots of time overall. Instead of spending 30 minutes assigning textures to objects in a scene, you could just spend 5, and your work is also less tedious.

How would you like to feedback the changes you made to the host app - that is the question - and you don't have an viable answer for it yet.

Because when you open the scene, this plugin reads that scene library file and attaches the materials to the objects. This way you could even change the material of an object in the Maxwell GUI directly if you want.

So using this method, you have the option of changing materials and material options in two places, both host app and Maxwell, but the info is stored in ONE place. Does it really sound like such a dangerous approach?

Another advantage, what if your scene gets corrupted (ask Max users about this )? With a scene library file, all you have to do is reimport the scene to your host app, load the library file and the material assignment is done, in 5 seconds.

I really don't understand why more 3D software doesn't save a separate material file. Because when something happens to your scene, most of the time you are importing the geometry from somewhere else, which takes 10 seconds, but it's the re-texturing of everything that will take you 1 hour.....

[Kabe]

How would you like to feedback the changes you made to the host app - that is the question - and you don't have an viable answer for it yet.

Because when you open the scene, this plugin reads that scene library file and attaches the materials to the objects. This way you could even change the material of an object in the Maxwell GUI directly if you want.
[...]
Another advantage, what if your scene gets corrupted (ask Max users about this )? With a scene library file, all you have to do is reimport the scene to your host app, load the library file and the material assignment is done, in 5 seconds.
I really don't understand why more 3D software doesn't save a separate material file.

Mihai, the problem is that any complex scene must be converted to triangles for an external renderer. Usually this happens in a transparent way so the plugin has no idea at all how the host app constructed the objects it gets. When I have a boned character or another object created by a complex generator or a particle system, all I get in the end is a bunch of triangles. Even if I would reimport that later, this is useless as a backup, and it's useless as a material reference as well.

So, there can't be a simple roundtrip for anything but the most simplistic scenes.

An export plugin could write out an additional *host* specific material mapping file (or a "black box data block") that maps the Material list from the MXS to the host specific object mappings.
After changing Materials in the Maxwell GUI the plugin could try to remap the changes using the host specific mapping it wrote out earlier. Sounds clumsy? You bet, coz it is.

As I said, I have not heard a good solution for this reimport problem yet. And before I have, I would suggest not to implement it...

Kabe

[Mihai]

Mihai, the problem is that any complex scene must be converted to triangles for an external renderer.

Is this what the Max plugin does now for instance? First convert all scene geometry to triangles before sending it to Maxwell? Because no matter how big the scene is, after you click render in Max, Maxwell starts almost automatically and starts voxelising, so I don't know when this conversion to triangles takes place.

I don't know what/how everything is stored in the mxs file....

I don't know how the material references are stored, is it per triangle?

Now, could it be possible that Maxwell itself could write this scene material library file in a way that could then be read by any host plugin written for Maxwell? It would just be a simple file telling the host this object has this material. Perhaps this is not possible because of the way the scene info is stored in the mxs, perhaps it's not using object names at all...

An export plugin could write out an additional *host* specific material mapping file (or a "black box data block") that maps the Material list from the MXS to the host specific object mappings.

No, not a host specific mapping file, a general file, maybe in xml format, just:

floor > mat1
ceiling > mat2

Furthermore it wouldn't be 'the material list from the MXS', Maxwell would read this exact same xml file and know how to apply materials to objects.

But like I said, if the mxs stores some object references...if it just stores it as "these bunch of triangles get this material", then ofcourse it wouldn't work so well.....


I don't see what's so clumsy about this. You get to change things both in host and Maxwell if you wanted too, while having only one scene mat file to keep track of.

XSI now for example has a scene 'table of contents' file written in xml which it reads to speed up opening of scenes for one thing and keep track of things. So for example if you want to change rendering params, you just have to open this xml file, change one number and send off the scene to mentalray. Also you don't need to have XSI installed on every machine.

So this 'table of contents' file I'm talking about that would be written by either the host plugin, or Maxwell would be in the same format, and it would be up to the host plugin to interpret it in such a way that it can correctly apply the materials. In ALL modeling software you are given the option to name your object and so logically the host plugin will have access to this name.

[Frances]

Mihai, can you and Kabe just make a simple bullet list of what you think the GUI should be capable of? Your words are painful to read. And there are so many of them.

[Kabe]

Mihai, the problem is that any complex scene must be converted to triangles for an external renderer.

Is this what the Max plugin does now for instance? First convert all scene geometry to triangles before sending it to Maxwell?

Of course. Take a look at the Maxwell SDK. An MXS already is host independent, which means that most of the host info already is converted.
It's a bit of reading, but you get the idea.

Now, could it be possible that Maxwell itself could write this scene material library file in a way that could then be read by any host plugin written for Maxwell?

It is probably possible, but *way* beyond the scope of Maxwell... There is no such format outside of Maxwell which would be capable to transmit such data, FBX is the thing that's closest to it. You simply can't transfer such information from Lightwave to Cinema directly, bacause they use different concepts, so they just don't match. It's "host specific black box data", bunch o'triangles or nothing at all.

XSI now for example has a scene 'table of contents' file written in xml which it reads to speed up opening of scenes for one thing and keep track of things. So for example if you want to change rendering params, you just have to open this xml file, change one number and send off the scene to mentalray. Also you don't need to have XSI installed on every machine.

I don't doubt that such a thing would have it's uses. However, it works like this in a roundtrip manner only if both of the applications use a common format.

So this 'table of contents' file I'm talking about that would be written by either the host plugin, or Maxwell would be in the same format, and it would be up to the host plugin to interpret it in such a way that it can correctly apply the materials. In ALL modeling software you are given the option to name your object and so logically the host plugin will have access to this name.

For instance - Cinema doesn't enforce unique names anymore, because it doesn't use names internally. This was a huge step forward. Referencing by names is just bad.

Kabe

[Kabe]

Mihai, can you and Kabe just make a simple bullet list of what you think the GUI should be capable of? Your words are painful to read. And there are so many of them.

I'm sorry Frances, but even in a world of Powerpoint presentations there's a lot of stuff that doesn't fit on a bullet list.

However, I'll work on a picture that hopefully will clean this Mess up in a way

Cheers

Kabe

[Mihai]

Just a note.....

bunch o'triangles or nothing at all.

I didn't mean transfer geometry data, I ment if both the host plugins and Maxwell would be able to write the exact same object>material list.

Does it make sense what I want to say?

For example you can write the exact same xml file using ASP or PHP...both ASP and PHP can read that same file (using different methods) to do the same thing.

That's what I'd like to happen here...both the host plugin and Maxwell should be able to read/write that file, and both host and Maxwell should be able to assign materials to objects using that file.

I'm only talking materials here, nothing else. I don't want any geometry data passed back from Maxwell to the host app.

But again I don't know how this material info is stored in the mxs file....

[Kabe]

I didn't mean transfer geometry data, I ment if both the host plugins and Maxwell would be able to write the exact same object>material list.

[...]

For example you can write the exact same xml file using ASP or PHP...

[...]

But again I don't know how this material info is stored in the mxs file....

Yes, Mihai, I understand what you say. However, this is a problem with different data structures, not with implementations.

For shure the host and Maxwell could read the same file (your ASP/PHP example). However, the problem is not the reading, which is an implementation detail.

The problem is that every host and Maxwell have quite different ways to model that object > material relation (which is not a clear relation anyway), because their whole object trees look different - and they have to for many reasons. It's the content and it's structure that is vastly different.

Take an example: If you use Indeaign to write out a Postscript file for a typesetter, then the result looks the same. You even can reimport that file later in Indesign - well, sort of. However, you loose all the internal structure you had in Indesign while doing so.

There's no solution for that problem afaik

Kabe

[Frances]

...
I'm sorry Frances, but even in a world of Powerpoint presentations there's a lot of stuff that doesn't fit on a bullet list.
...
Kabe

Yes, like explanations of why you think your proposed features would be good and why someone else's would be bad.

[stonelli]

The translation engine is the key here. If it slows down any portion of the two (host program and/or maxwell standalone), or is insuffient in its execution then it really does not matter what you have in the individual components (material editor, converters, render console, host program) the whole system fails and one is left with software that is frustrating to use.

I recommend you add this component to your list of the GUI components for Maxwell Render because without it, or the assumption that this will be assumed to be included is an oversight that could wreak havoc on this wonderful proposal.

It is seeming more and more to me that it would be best if Maxwell render were able to reference files for the programs for which it has/would have internal plugins, on the fly.
This way one would do all the modelling in their program of choice and materials and lighting in MR (I guess you would need the ability to detach elements from a layer if you needed to assign different UVW to those elements, or wanted better control on lighting).

That way we would all have the same MR workflow and NL could concentrate on just one main engine and many translators.
With FileLink in MAX I have to reaload a scene when the linked one has chaged. Personally, I don't mind this at all, in spite of the fact that the option to do this automatically would be welcome. What I do care about is the fact that once I have assigned a material to a layer it will remain assigned through the iterations or substitutions of the link.

Any way, I get really scared when I hear talk of parallel material libraries, doing an initial assignment in the host and refinining in MR....