Max.NET: Finally got material / texmap working together. A few questions

Hey Marsel,

I finally got my custom material using a custom TexMap working in both viewport and rendering. Pretty happy with that. One more step done in the evaluation process, hehe.

Now, small question : Some of our artists use the mentalRay renderer instead of the default scanline renderer, to preview their stuff. When I switch renderers to use mentalRay, my custom material appears as "Not Supported" (grayed out), in the material editor, when clicking on the material type selector. I searched a lot in the interfaces I use to see if I was missing a property or member override, with no luck. I finally attempted something hacky : since the sandard material, composite material, etc... are compatible with mentalRay rendering, I decided to have my material descriptor to return the "Composite" material class ID. Then material appeared as compatible !

Question 1: am I correct that mental ray decides what material is compatible or not, based on the classID ? Is there a way to create a custom material that will work under mental ray too ? If so, is it possible to do it with MAX.Net ?

Question 2: I based my custom material on Mtl. I know that a scripted material based on StdMat works under MentalRay. I was wondering if basing my custom material on StdMtl (not sure of the syntax) would fix the issue. The only thing I don't get is why we have to implement so many abstracts methods when subclassing a type like "StdMat". Is there a reason all these abstracts methods are abstract ? shouldn't they be just "virtual" ?

Thanks,

---
Psaii

12 August 2010

#2249

EPHERE

Hi Michel,

I finally got my custom material using a custom TexMap working in both viewport and rendering. Pretty happy with that. One more step done in the evaluation process, hehe.

Great to hear!

Question 1: am I correct that mental ray decides what material is compatible or not, based on the classID ? Is there a way to create a custom material that will work under mental ray too ? If so, is it possible to do it with MAX.Net ?

I assume that you refer to a texmap that would with with MR (not a material)? From what I know, in C++ to get your texmap properly translated to MR you need to do several things:

Derive your Texmap class from imrShaderTranslation (as well as Texmap) and implement following methods:
- GetMRShader
- ReleaseMRShader
- NeedsAutomaticParamBlock2Translation
- TranslateParameters
- GetAdditionalReferenceDependencies
Derive the class descriptor from imrShaderTranslation_ClassInfo and IMtlRender_Compatibility_MtlBase (as well as ClassDesc2) and implement following methods:
- GetApplyTypes from imrShaderTranslation_ClassInfo
- IsCompatibleWithRenderer from IMtlRender_Compatibility_MtlBase
Create a custom 'hidden' MR shader for your map (.dll and .mi files) and place them into 3dsmax/mentalRay (3dsmax/mentalImages in 3dsmax 2011 and up) directory

If you do that and call the Init() methods of IMtlRender_Compatibility_MtlBase and imrShaderTranslation_ClassInfo Max will show your map when both- normal and MR renderers are active, and if you use the map with MR renderer it'll pass/translate the parameter block parameters to your MR shader where you can use them to produce your result.

I haven't even started thinking about how to translate something like that to Max.NET to be honest. Multiple inheritance plays an important role here and its not supported in .NET There would probably need to be a special case for creating MR-compatible texmaps through Max.NET

The only thing I don't get is why we have to implement so many abstracts methods when subclassing a type like "StdMat". Is there a reason all these abstracts methods are abstract ? shouldn't they be just "virtual" ?

All the abstract methods are translated from pure virtual methods in C++. If a method is just marked virtual it should also be virtual in the Autodesk.Max.Plugins version of the class. This is the way it should work, maybe something is not right though. I guess I'll need to make a Mtl example to figure these things out.

Marsel Khadiyev (Software Developer, EPHERE Inc.)

13 August 2010

#2257

psaii

Thanks for the information, that helps ;)

Regarding the last part (pure virtuals), if you take the standard material for example, StdMat2 :

MAX.Net :
public abstract bool IsFaceted { get; }

Max Header File (inline override) :
BOOL IsFaceted(){ return GetFlag(STDMTL_FACETED); }

Maybe I'm looking at the wrong class, but if StdMat2 is actually a wrapper of StdMtl2, "IsFaceted" shouldn't be abstract at all in the wrapper. Actually, I don't see why there would be any abstracts at all in a working class like that, since they're already instanciable and used in Max ;)

Hope it helps,

---
Michel

13 August 2010

#2261

EPHERE

Aha, I see that you're referring to StdMtl2 which is, again, located in samples (not part of Max's main SDK). StdMat2 is a different class (which I presume StdMtl2 derives from). In StdMat2 IsFaceted is abstract:

virtual BOOL

IsFaceted ()=0

and thats what Max.NET wraps. I think this is part of the same discussion about including these sample classes in the SDK. I need to consult with some people about doing that for next build, will let you know.

Marsel Khadiyev (Software Developer, EPHERE Inc.)

13 August 2010

#2263

psaii

Hehe ;) Good, that explains it ;) was wondering why two different names existed for the material hehe,

Thanks

13 August 2010

#2265

EPHERE

Got to love the (lack of) naming conventions sometimes :)

Marsel Khadiyev (Software Developer, EPHERE Inc.)

Posted by:		psaii
Data created:	12 August 2010