Cloning materials with colour texture bitmaps
-
On 10/04/2014 at 11:21, xxxxxxxx wrote:
User Information:
Cinema 4D Version: R15 Stud
Platform: Mac OSX ;
Language(s) : C++ ;---------
I'm trying to clone a material from one document to another.If I use the following...
BaseMaterial *newMaterial = (BaseMaterial * ) oldMaterial->GetClone(COPYFLAGS_0, NULL);
...I get a copy of the material in the target document but the bitmap which is used in the texture for the colour (color for our overseas friends) channel is not copied across. Thus the new material is missing its colour channel texture bitmap.
Do I have to separately clone the bitmaps and if so how do you iterate a list of bitmaps used in the source document? This seems unlikely.
I have a feeling that it is my COPYFLAGS that is wrong but I don't know for sure.
-
On 10/04/2014 at 12:46, xxxxxxxx wrote:
Normally I don't advise people to use CallCommands because the built-in undos in them can be a massive headache to deal with.
But in this case. It might make sense to use them.//Copy the active materials
CallCommand(300001022);
//Paste the copied materials
CallCommand(300001023);-ScottA
-
On 11/04/2014 at 00:30, xxxxxxxx wrote:
Thanks for that Scott.
Works very well except the calling the paste command causes C4D to display the message box...
The following textures are not in the current project or search path! Do you want to change the path information to absolute paths?
myfilename.bmp
The original texture was in the default /tex folder below the old.c4d file. In other words it was a relative path.
C4D is no doubt showing the message because it wants to know whether how to handle the bitmap path relative to the new.c4d project.
Unfortunately since this is for a plugin, I'd like to find a way to avoid the message and also to avoid problems with leaving the new.c4d project with missing textures.
Any further ideas?
-
On 11/04/2014 at 07:04, xxxxxxxx wrote:
Copying the BitmapShader does not copy the texture file. You have to copy the file for yourself
to the required destination.Best,
-Niklas -
On 12/04/2014 at 00:41, xxxxxxxx wrote:
Thanks Niklas. I was beginning to suspect that might be the case - no problem. I assume that the internal linkage between the material channel and the texture file is simply based upon filename embedded within the material and that there is not some hidden internal symbolic link?