Mihai Iliuta wrote: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