<br><br><div><span class="gmail_quote">On 8/16/07, <b class="gmail_sendername">Mathias Wein</b> <<a href="mailto:firstname.lastname@example.org">email@example.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>Campbell Barton wrote:<br>> Id suggest that custom material types make use of blenders internal data<br>> where possible.<br>> (Matt - maybe this is implied in your proposal, not sure...)<br>> For example, you have a scene. render in Povray and set the color to
<br>> just the right color, then decide to try renderman, when changing the<br>> material types youd not want to loose the color.<br>><br>Well, my "scripting department" (Bert Buchholz) strongly voted against
<br>mixing blender settings with external renderer specific ones, and he<br>pretty much convinced me it is the better way.<br>If the blender material can't be converted, make a complete and clean<br>interface for the material type, it is confusing if renderers overwrite
<br>each other's settings, and mappings will become unintuitive if you try<br>to reuse too many settings, too few will have the same meaning.<br></blockquote></div><br>I'm with Mathias here, re-using bits and pieces of Blender settings (as in the variables in the Material DNA Struct) is not a good way to go at all. Not only are the settings not equal or even relevant from renderer to renderer, but especially cherry picking what of Blender's material settings will be reused and what won't is something that would be extremely inconsistent and confusing. As a user you don't want to be in the situation of times past with the old Yafray where the same sliders in Blender will do slightly different things depending on what renderer is selected, and you have to remember in your head 'oh the X slider really means Y'.
<br><br>What I implied in my proposal was not reusing the data, but *conversion*.<br><br>Each render plugin should have a conversion function, that takes the settings of a Blender material and converts them to settings in the native representation, doing a best-guess lookalike estimate, so that the results look similar when rendered.
<br><br>This conversion process would be used twice:<br>* When rendering a 'Blender material' in an external renderer<br>* When changing a 'Blender material' to an eg. 'Yafray material' in the material type menu.
<br><br>How that data is stored in the native format for that renderer I don't really know or care about, but it sounds like ID properties would be a good way to go. However even if using ID properties, the user shouldn't really care or know the difference - there should still be a series of material panels, with sliders and colour pickers to control various aspects of the material, just the data internally is coming from a different source (id properties rather than material dna struct).