THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 26/02/2005 at 12:42, xxxxxxxx wrote:
Cinema 4D Version: 8.0+
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;
Maybe I'm being thick here, but I cannot find a way to get to the User Data of something in the A.M. I want to set a link (yes, the user wants to see it also) in the UserData of a Material.
On 26/02/2005 at 14:14, xxxxxxxx wrote:
I see that it's called "DynamicDescription". Okay, how does one create and add a DynamicDescription to a Material (or anything)? What ID does one set for the BaseContainer when calling DynamicDescription::Alloc(const BaseContainer& bc)?
Examples, source, explanations - these are all amazingly useful things. Why is it that there are those out there who know how to do these things, but never answer? It's a FORUM, not a "Mikael Sterner answers your questions" exchange.
On 28/02/2005 at 12:46, xxxxxxxx wrote:
Yes, everyone feel free to help yourselves together. Though I'm afraid me answering questions is an integral part of this forum...
The documentation seems to be a bit vague in this area. The container should be of the same format as described on the Description class page. So you would for example have:
BaseObject* obj = doc->GetFirstObject();
DynamicDescription* ddesc = obj->GetDynamicDescription();
BaseContainer bc = GetCustomDataTypeDefault(DTYPE_LONG);
DescID id = ddesc->Alloc(bc);
obj->SetParameter(id, GeData(42), 0);
On 28/02/2005 at 13:05, xxxxxxxx wrote:
I will try this out if necessary. If I can get a PluginMaterial to include Material channels, then this would be unnecessary.
The problem is that I am trying to make an enhancement to the C4D Material to include a Shader Node Tree (at the Material level) supported by a PluginShader in the Texture. Putting the tree in the Shader would be complex and odd for material level connections - only one tree is necessary per material (think ShaderMaker or Poser 5 Materials).
Remember that this is not 8.5 (Layers) or above. This is 8.012/8.205 SDK. It'd be great to jump on the bandwagon for each new SDK and dump those poor users who don't upgrade, but I prefer to find a baseline and support it from there in a way that works in later versions (so far my plugin works from 8.0-9.1). If at some later time the plugin is 'finished' and feature support for later versions is worthwhile, then I can make a special version. Otherwise, I will not try to maintain eight versions of the same plugin as well as my sanity with respect.
On 28/02/2005 at 13:33, xxxxxxxx wrote:
Gah, 8.0 here and 8.0 there. What about my sanity, having to support eight different legacy SDK versions?
Ok, but I think I understand what you want now. Then it's unfortunately not possible, regardless of version. You would have to duplicate the built-in channels, just like the various SLA materials do. I believe I would recommend doing your tree as a shader instead.
On 28/02/2005 at 13:53, xxxxxxxx wrote:
Ah, thanks, Mikael. Well, I have a backup plan which doesn't involve duplicating built-in channels - just a parallel set of plugin materials to the C4D materials (and the PluginShader to pipe in the node calculations and settings). Add the shader, it adds the plugin material if not already added. The plugin material is strictly a dummy for storing and editing the shader nodes of the 'real' material.
As for legacy SDK support - would it were that all users always immediately upgraded to the latest release!
My plugin fills a gap that started with R8.0 (by no fault of Maxon's), thus the baseline version for my plugin support. You'd be amazed at how many of my registered users are using R8.x! (36%)