Seting and getting a shader from a description dia

On 19/07/2013 at 12:23, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R14 
Language(s) :     C++  ;

Hi! I'm still pretty much a noob when it comes to C++ so even the simplest things, that would take me 2 minutes in Python, can get very tricky. :)
At the moment I'm struggling with assigning a preset noise shader to SHADERLINK GUI element in an object plugin.

Thats what I have so far.

  // This part happens in the Init method of the plugin  
  BaseShader *noise = BaseShader::Alloc(Xnoise);  
  data->SetLink(TEXTURE, noise);  

Obviously there's something wrong with this, because I don't see the shader, when I start the plugin. I know, that the Basecontainer basically points to a TEXBOX_GUI element that contains the shader link, but I don't know how access it.

The other part I'm struggling with is the get part of the equation, where I want so sample the shader that's set in the GUI.

Here I'm using this:

/// This is in the ModifyObject method  
  texture = (BaseShader* )data->GetLink(TEXTURE,doc,Xbase);  
  if (texture) {  
      if (texture->InitRender(InitRenderStruct()) != INITRENDERRESULT_OK) return FALSE;  
  ChannelData cd;  
  cd.p = Vector(0,0,0); // this is just an example vector  
  value *= texture->Sample(&cd).x; // This is where things go sour  

It works somewhat half way, because I can load some shaders that I manually assign during runtime, but whenever I pick a noise shader I get a straight crash. The debugger is pointing me to the Sample method of BaseShader in the api to be the cause for the exception.
I'm guessing it has something to do with the volumetic information of the ChannelData, because it doesn't happen with simple 2D shaders, but I'm not sure.

I hope someone can help me out. :)

On 19/07/2013 at 14:40, xxxxxxxx wrote:

BaseContainer::SetLink() only establishes a _link_ to the shader, it does not store the shader. You have
to insert the shader into the shaderlist for this to work. This will also solve the rendering issues.

BaseShader\* noise = BaseShader::Alloc(Xnoise);
if (noise) {
	data->SetLink(TEXTURE, noise);


On 19/07/2013 at 16:06, xxxxxxxx wrote:

Hey Nik, thanks a lot! The InsertShader method did the trick with initializing the shader. When I was trying to fix this on my own, I came across a code snippet where InsertShader method was used with a material.
Didn't even cross my mind, that this could have been applicable to my case. Like I said, coming from Python all of this still seems kinda alien.

Unfortunately sampling the noise shader still throws an exception. More specific, it's the sla.cdl64 thats causing the problem (Which probably doesn't help a lot, because it's simply the dll where the noise shaders are implemented).
Do you have any idea, what might be causing this?

On 19/07/2013 at 16:28, xxxxxxxx wrote:

If I remember correctly, you have to intialize the ChannelData manually. Eg. cd.vd will be some
random number from the stack because there is no constructor for the ChannelData struct, or
to be more precise, the constructor does not initialize the values. Pretty uncommon in C++ and
IMHO its an unnecessary drawback in the API.

On 20/07/2013 at 00:47, xxxxxxxx wrote:

Fantastic, everythings working A-OK now! Who would have guessed? :)
It's really something, that you just can't know until somebody tells you. Sometimes writing in C++ seems a bit more hostile than it needs to, but you just can't argue with the speed.

BTW, I used your DescEdit Plugin to create my descriptions. Really helpful tool, but it could need a little overhaul here and there. Are you still developing this or will 0.9 BETA be the last version?

On 20/07/2013 at 03:55, xxxxxxxx wrote:

I certainly agree. There's a thread from me around of the exact same problem. You do not expect
a structure or class instance to be un-initialized after constructing it in C++ (except if you know it
is coming from a C library for instance).

Oh that's nice to know! I didn't get much response to it and, to be honest, I don't use it myself.
0.9 BETA was the first and last version, hehe. No kidding, I was planning to rewrite it soon. I could
not write C++ back then, but the new version will be a native plugin with WYSIWYG feature.


On 20/07/2013 at 07:40, xxxxxxxx wrote:

Us programmers can be an ungrateful bunch, right? ;)
But seriously I guess you not getting too much response to DescEdit is due to this being more of a niche application. For my part I think it's super annoying having to do the descriptions by hand, so your plugin is a real timesaver. I sometimes wonder if the folks at Maxon also write them manually or if they have some special ResEdit for descriptions that they are holding out on us.

I think it's not a problem at all that DescEdit was written in Python, for there's nothing time-critical going on. Give me an overhaul of the export command (No more entering bogus filenames) and some drop down menus for the keywords and options and I'm a happy man. ;)
Naturally WYSIWYG would be a dream come true, but that's really a quiet elaborate endeavor.