[DELETED]

DELETED

[stonelli]

I am interested in Maxwell because I use MicroStation and it's renderer simply has not kept up with time.
When I firs heard of MR I my understanding was that it would be a program into which you would import geometry created in other programs to which you would then assing materials and lighting.
Now I have seen it being used by our Viz dept. and have been reading through the NG so I know that the plugin, certainly in it's current state, does just more than export geometry.
Putting aside the issue of how you would do lighting if MR was simply importing geometry by layer, it seems to me that for NL, it would be easier to provide many geometry only export modules and concentrate on the standalone. That way we would all get the same MR experience and updates etc. etc. would be much easier.
NL has already kind of committed to, eventually, make a plugin for MS. I wuold be fine with that,as well, but would rather have what I originally envisioned as I think it would allow NL to spend less time on plugins and more on MR itself.

[Mihai]

About materials, that's how I thought they would work as well.

In the host app, assign a "placeholder" material with a standard name like 'Plastic'. So Maxwell knows when it imports the scene to apply a Plastic material to that object. The advanced material settings, you apply in Maxwell. If you need to update the scene, Maxwell should know on re-import to keep the advanced settings the user has set on that plastic material.

I think this would be the easiest way to handle it, to make the different plugins as simple as possible. Although the plugins would also need to support objects with materials assigned to poly selections.

[Miles]

My understanding/hope was on the same lines as bakbek and stonelli

[stonelli]

If you need to update the scene, Maxwell should know on re-import to keep the advanced settings the user has set on that plastic material.

Agreed, I currently use FileLink in MAX for the same reason (Updates or geomtric options on the subject)

Don't know about the place holder material. Max's FileLink does not require it. As long as the geomtry is on the layer you have assigned a given material to in Max, that material will be assigned to subsequent links or re-links of that layer.

If I need to refine my assignments to the element level, I edit mesh detach from within Max and do the special assignment there.

This is why I made the comment of "lighting aside", earlier. I don't know how things work if the scene is modelled in Max but when it is a link of a DWG the material assignment is by layer, which makes lighting a bit less flexible.
I could be missing something, as I've said, I've only see it used as the Viz team is being a bid greedy with their licenses an NL hasn't seen fit to issue a demoware yet (I hope)

[ingo]

........In the host app, assign a "placeholder" material with a standard name like 'Plastic'. So Maxwell knows when it imports the scene to apply a Plastic material to that object. ....

Why ? If you use your normal naming convention in your host app like always most work is done. Maxwell just needs to import this settings, no matter if this are just polygon selections (even for emitters) or complete objects.

You than can do the normal texturing the same way you have done it in your host app before you worked with Maxwell, means adding several layers of texture maps/shaders/gradients.... and of course basic and special Maxwell settings for every of these materials you named in your host app.

[Kabe]

When you press render, the plugin exports geometry, uv, and material definitions.

What i say is. Do the same, but add one more step, you will SUBSTITUTE the modelers materials, with native maxwell materials.

If i am wrong somewhere and i miss smthg please someone tell me so.

I don't think that "substitute" is the right term. How the Maxwell material is integrated in the host environment is essentially a decision the plugin coder will make, and it may even depend on the host itself.

Basically I think it makes sense to design the system around "Native Maxwell Materials" = NMMs. These are designed in a standalone material designer which allows to edit Maxwell Specific Magic (MSM). In the host they have just a few user input fields for some user parameters and the maps. NMMs are cross platform and completely host independent, and their format - at least for the user interface part - is clearly structured and documented.
BTW: If there would be some method in M~R to render out previews for materials for the host application, then this would certainly be a big bonus to preview the user changes in the NMM inputs and maps.

The host application plugin then uses the most elegant approach common to the host to store references and parameters for the NMMs. In Cinema this would be a material tag, in other applications different structures would be needed. How these interact with the host, is not a decision that primarily affects M~R as a render system.

If you would like to write a plugin that uses substitution tables, feel free to do that - I shure wouldn't do This whole substitute idea would add a lot of overhead - both for the plugin code boy (or girl) and for the users - and it doesn't have big advantages. It introduces a lot of dependencies and side effects.

Kabe

[Mihai]

Ofcourse the Maxwell GUI should have it's own material editor, with presets one could save and share, I think that's what you're saying Kabe?

But how should the connection work?

Export scene to Maxwell>Make material adjustments>Save scene as a Maxwell scene to be rendered.

Now, I need to edit an object in my scene, what do I do?

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

The thing I mentioned about placeholder materials is really nothing more than naming your material Plastic, and when Maxwell finds a mat with that name, it automatically converts it to a plastic. Just a convenience thing. Any deeper settings like bump, speculars etc should be handled inside Maxwell.

Now that I think about it, bitmap assignment and tiling should be handled inside Maxwell, not the host app.

The plugins should not have anything to do with integrating Maxwell mats in the host app.

[Kabe]

Ofcourse the Maxwell GUI should have it's own material editor, with presets one could save and share, I think that's what you're saying Kabe?

Yes.

But how should the connection work?

Export scene to Maxwell>Make material adjustments>Save scene as a Maxwell scene to be rendered.

No. The connection works with material libraries. The plugin uses these libraries to assign NMM data and parameters in the host application.

Now, I need to edit an object in my scene, what do I do?

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

That's exactly the reason why you have to assign the Materials in the host application. Host applications have good established mechanisms to store such data.

The thing I mentioned about placeholder materials is really nothing more than naming your material Plastic, and when Maxwell finds a mat with that name, it automatically converts it to a plastic. Just a convenience thing. Any deeper settings like bump, speculars etc should be handled inside Maxwell.

Who keeps track of the names? The user? How do you avoid unintended changes? How do you show these to the user? How do you resolve name conflicts? Localisation?
Believe me, this would create a mess, but no workable solution.

Now that I think about it, bitmap assignment and tiling should be handled inside Maxwell, not the host app.

Why? Why mess around with the user's common workflow? Not doing it creates a new layer of complexity that does not have *any* positive value afaiC. If you would like to stick to that point, you should justify it a bit

The plugins should not have anything to do with integrating Maxwell mats in the host app.

Ehn... what do you mean by that? At least the plugin has to store proper references to the materials and their input parameters in the host data file. References certainly does not mean just "names" BTW.

The kind of plugin implementation is IMO a detail that does not need to be fixed. If someone's willing to implement the substitution solution you and buffos seem to like, he can do so ("She" won't do such a folly thing .

Though showing a Material simulation in an host app is certainly not a requirement, it could user enhance control quite a bit. But again: This is not the primary decision right now for NL.


Kabe

[Mihai]

No. The connection works with material libraries. The plugin uses these libraries to assign NMM data and parameters in the host application.

But how would the host app plugin have access to advanced material settings? How would a preview of that material be handled?

These things would only be available in the Maxwell GUI, with it's material editor.

So the question, what material settings would you set in your host app plugin, and what settings would you set in the Maxwell GUI?

Because in that case, you would have duplicates, for example you will be able to set bump strengh in the host app, but then you could also change it in the Maxwell GUI?

Why not simplify plugin dev, and just put all the functionality of applying materials in Maxwell?

Now that I think about it, bitmap assignment and tiling should be handled inside Maxwell, not the host app.

Why? Why mess around with the user's common workflow? Not doing it creates a new layer of complexity that does not have *any* positive value afaiC. If you would like to stick to that point, you should justify it a bit

Well, for the reason stated above. How do you decide which settings the user CAN set in the plugin and which settings they can set in Maxwell?

For me it seems logical to give the user access to ALL material settings in one environment. Workflow adaptation is no big deal really, we are just talking about: push button, select bitmap. The uv's will already have been imported by the plugin.

Otherwise how did you imagine it? Have the texture assignment in the host app, but have the advanced settings in Maxwell? Why go back and forth if all you want to do is change the bitmap?

I'm trying to think how you imagine the workflow of the connection.

The plugins should not have anything to do with integrating Maxwell mats in the host app.

Ehn... what do you mean by that? At least the plugin has to store proper references to the materials and their input parameters in the host data file. References certainly does not mean just "names" BTW.
Kabe

What I mean is the plugin should only send geometry info together with material assignment info ie: these polygons have this material assigned to them.

But the material info would only describe the type of material, nothing else. No bumpmap settings info and so on.

I don't see a naming convention problem, people wouldn't actually have to write the names themselves, the plugin could just offer them another material TYPE (like phong, blinn etc), you just have a dropdown: Maxwell Plastic. They could name that material anything they wished.

[DELETED]

DELETED

[Mihai]

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

But like I wrote above, I don't think it will be possible that each host plugin will be able to set every material setting that the Maxwell material editor will support. For example perhaps the Maxwell material editor will let you adjust reflectance curves directly. How would you adjust that in your host app?

Also when Maxwell updates with a new material setting, you would have to change all the plugins again to support that new setting.

[ingo]

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.

When you add another room you can name all the polygones like before if they have the same materials, maybe only the floor is different, so you call it "floor 2". When you import both rooms into Maxwell you still have the three materials (with the settings you made before) and a new material called "floor 2".

Thats all

[Mihai]

Ah ok, I see we are talking about really the same thing. Although I don't see the need for a correspondance list.

[Kabe]

But how would the host app plugin have access to advanced material settings? How would a preview of that material be handled?

The host doesn't need to have access to advanced material setting, just to the user settings like maps or basic colors and maybe other similar easy settings. Stuff like metal ior or such must be set in the Maxwell Material Creator.
The preview of such a Materials should be handled by Maxwell Render in the background, and the previz in the host is up to the plugin.

for example you will be able to set bump strengh in the host app, but then you could also change it in the Maxwell GUI?

Bump strength is user input. The Material might set a default, but the user can overwrite that parameter in the host app. This is beginner's stuff.

Why not simplify plugin dev, and just put all the functionality of applying materials in Maxwell?

Because beside a few freaks nobody will use this app anymore. This is a renderer, not another 3D app. To efficiently make the whole texturung in Maxwell, this would need an awful lot of additional work. And it doesn't make any sense.

How do you decide which settings the user CAN set in the plugin and which settings they can set in Maxwell?

Using a check box? C'mon Mihai, there are dozens of apps out there that do stuff like this. If you would like to see a good system for it, look at node based systems.

For me it seems logical to give the user access to ALL material settings in one environment.

I agree that texturing should take place in one environment, but I don't agree that advanced settings for a new Material type necessarily belong here. If I design a new metal type, or some crazy new diffuse type, I don't need to do that in the same app I use to texture my models.

Workflow adaptation is no big deal really, we are just talking about: push button, select bitmap. The uv's will already have been imported by the plugin.

What kind of silly scenes are you talking about? We're talking about object selection, and you better make this visual. We're talking about massive scenes with hundreds and thousands of objects. You have no solution how to keep track of changes in the modeling application, and there really is none.

It's a Certified Bad Idea CBI™ to feed the changes you made in a later step of the pipeline back to the previous steps, and it creates a development NIGHTMARE.

Otherwise how did you imagine it? Have the texture assignment in the host app, but have the advanced settings in Maxwell? Why go back and forth if all you want to do is change the bitmap?

Who said that? I clearly said that map assignment could take place in the host app.

What I mean is the plugin should only send geometry info together with material assignment info ie: these polygons have this material assigned to them.
But the material info would only describe the type of material, nothing else. No bumpmap settings info and so on.

That's another CBI™ - why can't I set the bump strength in the same app that I use to assign the texture? Nobody would buy such a concept.

I don't see a naming convention problem, people wouldn't actually have to write the names themselves, the plugin could just offer them another material TYPE (like phong, blinn etc), you just have a dropdown: Maxwell Plastic. They could name that material anything they wished.

Have you ever worked with applications that do name referencing? Older Cinema versions have, and I can tell you from first hand experience, that using names as reference is a CFBI™.
References by names in a user environment are error prone, they provide you with a whole class of new problems. They are bad design in any case, they are ugly hacks at the very least. NL will not do such a thing, believe me.

Kabe