[Mihai]

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!

But to me it seems logical that if Maxwell can read the tiling info sent by the host plugin (and obviously it has to), then it shouldn't be such a stretch to also be able to modify this tiling info from within Maxwell.

...and good night

[Kabe]

But to me it seems logical that if Maxwell can read the tiling info sent by the host plugin (and obviously it has to), then it shouldn't be such a stretch to also be able to modify this tiling info from within Maxwell.

To manipulate maps etc. you "only" have to show a list of materials. To show tilings you have to show the whole object tree, which requires a lot more interface.
Additionally the geometry might not even be a tree anymore in maxwell, but just a list of objects. After all, the MXS file is optimized to serve the renderer.

To be clear: I don't have a problem if this would be possible. However, I certainly would not classify that as a requirement.

I have a general concern with manipulating settings in the renderer anyway: You can't automatically feed the changes you made back into the host app.
So all the changes you make here have to be doubled in the host. Why should we go through all this trouble just to avoid running the host and the renderer side by side? I don't buy it. Mistakes should be corrected where they happen in the pipeline, so a wrong tiling should IMO fixed in the host app. Your mileage may vary - as I said, as long if this is an option, I don't have anything against it.

IMO there should be basically the functionalities in the Maxwell workflow:

The Maxwell Material Designer to build NMM libraries, set advanced settings and design new shaders. This is not for the faint of heart and many users won't touch it. Additional tools like the HDRI->MXI converter could be placed near it.

The Maxwell Plugin, that assigns NMMs and the other Maxwell tags, allows to set some user options (maps, colors, whatever the NMM's designer had in mind) and has the option to save out new NMM variants to the library. It also exports the scene to an MXS and starts the renderer

The Maxwell Render, that renders the MXS and puts out an MXI. As a bonus it could render out material previews in a faceless background mode to support material preview in the Maxwell Plugin.

The Maxwell Converter, which converts MXI -> TGA/TIFF/HDRI/JPG. Beyond simple conversion it allows to use postrender controls like ISO setting, Vignetting compensation or gamma control.

This does not neccessarily mean that it's all in one app, though it would have some advantages (ie. material manipulation in the renderer might be easier if the NMM Designer is in the same app).

Kabe

[Tyrone Marshall]

wow reading through all this i expect mxw 1.0 to be ready 2011 :%

I suspect this portion of the program is well underway and implemented. I have a feeling our current discussion is feedback data that helps them to refine what they are "implementing and thinking" relates to and surpasses our expectations.

[Tyrone Marshall]

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

Nothing is wrong with this and I do believe we touched on some of this in our poll and discussions about the maxwell materials in cinema 4d.

In the host application it is the addition of a new maxwell material in whatever form that can have access to the advanced material editor data.

[Tyrone Marshall]

IMO there should be basically the functionalities in the Maxwell workflow:

The Maxwell Material Designer to build NMM libraries, set advanced settings and design new shaders. This is not for the faint of heart and many users won't touch it. Additional tools like the HDRI->MXI converter could be placed near it.

The Maxwell Plugin, that assigns NMMs and the other Maxwell tags, allows to set some user options (maps, colors, whatever the NMM's designer had in mind) and has the option to save out new NMM variants to the library. It also exports the scene to an MXS and starts the renderer

The Maxwell Render, that renders the MXS and puts out an MXI. As a bonus it could render out material previews in a faceless background mode to support material preview in the Maxwell Plugin.

The Maxwell Converter, which converts MXI -> TGA/TIFF/HDRI/JPG. Beyond simple conversion it allows to use postrender controls like ISO setting, Vignetting compensation or gamma control.

This does not neccessarily mean that it's all in one app, though it would have some advantages (ie. material manipulation in the renderer might be easier if the NMM Designer is in the same app).

Kabe

This seems to all be related to the translation mechanism engine that talks in both directions from/to host application to/from maxwell standalone.

The handling of materials is strictly a database type function - the important link is the translation engine.

In the most perfect system, the translation engine must be good enough to not get in the way of the host program when information is being passed back and forth (example- you tweak the iso settings in the maxwell console- this should through the translation engine cause change to the iso setting for the camera in the host application) to interupt workflow and be so transparent as to render function smoothly to the end user.

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.

[Mihai]

The translation engine must be good enough to not get in the way of the host program when information is being passed back and forth (example- you tweak the iso settings in the maxwell console- this should through the translation engine change the iso setting for the camera in the host application) to interupt workflow and be so transparent as to render function smoothly to the end user.

No, I don't believe this is how it should work. It's dangerous passing back and forth like that between host app and renderer. There is really no need to either. Just a host>render connection is enough. The iso setting is really nothing that can't be forever adjusted, even after the render is finished.

Kabe has a point that if you change the tiling for example in Maxwell, then you get inconsistencies between host app scene and Maxwell scene....this isn't good either.

Talking about this more and more it looks really like the Material Editor should be the 'GUI' of Maxwell, and why not add to it also the ability to create and adjust mxi's, along with the postrender controls Kabe mentioned.

Keep the mxi viewer as it is (minus the option to create mxi textures with it), so we can adjust renderings like we do now.

So we'll have two options to control the iso/shutterspeed, both while rendering, and also opening the resulting mxi in the GUI/Material editor and adjusting it there.

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.

[Tyrone Marshall]

No, I don't believe this is how it should work. It's dangerous passing back and forth like that between host app and renderer. There is really no need to either. Just a host>render connection is enough. The iso setting is really nothing that can't be forever adjusted, even after the render is finished.

I wrote in a perfect situation this would be the best user experience. If you have to settle for the next level down, then this feature could be left out. But that does not negate the need for a translation engine that is robust and capable.

Kabe has a point that if you change the tiling for example in Maxwell, then you get inconsistencies between host app scene and Maxwell scene....this isn't good either.

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.

Talking about this more and more it looks really like the Material Editor should be the 'GUI' of Maxwell, and why not add to it also the ability to create and adjust mxi's, along with the postrender controls Kabe mentioned.

Keep the mxi viewer as it is (minus the option to create mxi textures with it), so we can adjust renderings like we do now.

I see no reason to split the maxwell console into two parts- it works wonderfully as a multifunction program in its current state- it is the render gui and mxi creation engine all at the same time- where you can convert hdri and ldri images to mxi format.

So we'll have two options to control the iso/shutterspeed, both while rendering, and also opening the resulting mxi in the GUI/Material editor and adjusting it there.
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.

Okay I agree with this, this sounds like the import/export description file I talked about a few paragraphs up.

[Frances]

It would be nice if camera tweaks in the GUI could be saved as a preset that could be loaded back into the host app.

[Kabe]

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

[Mihai]

Confusing again Kabe:)

Can you give an example of what you mean? Breaking the pipeline?

I'm just talking about that attached to a scene file you might have, give the option to have a simple file that tells the renderer which materials should be applied to which objects.

For example I've exported out my scene from my host app, but then I find a really nice collection of Maxwell shaders online, and instead of opening up my scene again in the host app, go through all the objects, selecting them, applying the mats, re-export, why not just do a quick edit in this scenes material library file? Open it up in any text editor.

If you mean by breaking the pipeline that now your mxs file will use other materials to render, than you have specified in your host app scene, then it shouldn't matter because in the host app plugin you will have the option to specify this scenes material library, so when you load that, it will load all the mats from that list, the same list you use for rendering.

It seems like a small convenience, but it adds up and could save time as well as being less annoying workflow.

[Hugh]

Ok, after much reading I can see that most input seems to be in favour of a comprehensive collection of plugins that allow a virtually transparent interface to the renderer. That would be great but my reasons for wanting a GUI capable of imported geometry at least as an additional option are as follows:

1 What if your 'host' applications use of UV mapping, materials set-up, cameras, etc. is a best awkward and what you would really like is a renderer with a sleek GUI with the capabilities I outlined when I started this thread.

2 When I purchased Maxwell, I assumed certain things when the term "Standalone" was used to describe it (see 4th paragraph down
under "What is Maxwell?" on the home page). In my opinion that term used in conjuction with a renderer implies application independance. I fail to see how a renderer reliant on plugins can be labelled as such.

[Kabe]

Breaking the pipeline?

I'm just talking about that attached to a scene file you might have, give the option to have a simple file that tells the renderer which materials should be applied to which objects.

[...]

why not just do a quick edit in this scenes material library file? Open it up in any text editor.

It's not that simple:

First the MXS should hold *all* the data, this include all the material settings. Otherwise you get into trouble when changing materials in the library. So - if you can exchange materials in the library, it should happen in Maxwell itself, so you could also see at least texture paths, and have access to some setting.
Then - if you use a text editor, you will make errors. Well, I do at least. Those errors in a pipeline are very hard to catch. And it's not just that it may affect the user, it requires a lot more error checking for Maxwell's parser that reads in that file later.

If you mean by breaking the pipeline that now your mxs file will use other materials to render, than you have specified in your host app scene, then it shouldn't matter because in the host app plugin you will have the option to specify this scenes material library, so when you load that, it will load all the mats from that list, the same list you use for rendering.

Do you think that this list easily translates into the host architecture?

I doubt it does, and here's why: The host has a completely different object list than the MXS file - and there's no ways around that. The MXS holds a huge amount of converted data which can not easily be reconverted, it probably does not even have a hierachic object tree. So to allow that the host plugin would additionally need to submit the hosts object tree with Material assignment list.

Additionally you will run into problems when the source scene changes in any way before the scene library is reimported.

I don't say it's impossible. But it is an awful lot of work for the plugin coder for very little effect. In their position I would clearly refuse to even specify that requirement.

It seems like a small convenience, but it adds up and could save time as well as being less annoying workflow.

Maybe it's a small convenience for the user. However, shure it would be a major pain in the butt for NL and every plugin coder. This would become a nightmare, and I mean it.

It's not that I totally dislike the idea - there's just a lot of bigger fish to fry. There's so much to do, and I think we agree that the core functionality must be implemented in a robust way. and even if this works, we all will have much more important issues than get scene changes in Maxwell back into the host automatically.

Kabe

[Kabe]

Text files are everywhere.

.Obj is a text file.
.Xml is a text file
.dxf is a text file.

A simple correspondance list should be text based. For many reasons.

You have no clue.

[Kabe]

Ok, after much reading I can see that most input seems to be in favour of a comprehensive collection of plugins that allow a virtually transparent interface to the renderer. That would be great but my reasons for wanting a GUI capable of imported geometry at least as an additional option are as follows:

1 What if your 'host' applications use of UV mapping, materials set-up, cameras, etc. is a best awkward and what you would really like is a renderer with a sleek GUI with the capabilities I outlined when I started this thread.

If UV mapping in your previous host is limited, then you are in trouble... this is not a trivial task.

However, I think that the solution will come through a solution like Matador Light: A standalone app that reads in a few standard formats, allows you to create UVs, to texturize and to set the camera - and which exports to M~R using the Maxwell SDK.

Though this discussion currently concerns plugins mostly, there's no technical reason why such a standalone "Texturing application" could not be build - maybe by a third party - by using the Maxwell SDK.

Kabe

[Kabe]

If you read the sdk, mxs does hold all the data.
That does not mean you cannot change data AFTER you have created the mxs.
Writing simple app that will read all materials defined in the mxs, read the correspondance text file and change the mxs file is very easy. I will do it as soon as the program is finished and finalised.

I'm rather uncertain if the SDK will provide methods to read MXS files. If it does, it's possible. Hacking a binary format without definitions is possible as well, but certainly not easy.

The point is that if they can create great plugins with all the functionality, they are more than welcome. BUT the problem is that this cannot be done and maintained for all those apps, and all the versions to come.

Of course it is. See my posting about "Black box data". The plugin has to know very little about Maxwell, and if properly implemented it has to know nothing about new Maxwell types. All it needs is a list of user options and a way to create previews - and even the latter is a kind of convenience thing.

THis is why i proposed just simple exportplugins for some of the applications. As an alternative.

So, what does you export plugin delivers then? A mesh and a material list? Well, then all that's needed is a OBJ->MXS converter that assignes the *.MTL file of the *.OBJ to Maxwell materials. Fine with me. Will require a lot of tweaking though, because OBJ is a very diverse format... but that makes sense if you need that. It's not production safe, but a neat hack at least.

Kabe