Questions of comprehension about the SDK
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 15/03/2005 at 03:34, xxxxxxxx wrote:
Robert, thanks for your answer. I think it makes things clearer now. So, just only a few comments
1. Ok
2. I would say from the programming point of view it should be possible to extend the existing objects, since they exist in the SDK as normal C++ - classes. The problem just would be how to get your new class into the standard methods of the XXData.
3. I have been "investigating" this a bit further and it seems that Init() is always called after the object has been created. So, actually with every call of Init() you get a new instance. How I found this out: I simple placed GeDebugOut()-calls into the default constructor, Init(), and so.
Well, this behavior still seems a bit weird to me. Why isn't it enough that the Object is created once the plugin is called from the menu (in the case of a tag or object-plugin)? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 15/03/2005 at 09:10, xxxxxxxx wrote:
2. Don't be fooled by the SDK!
The classes on display for 'built-in' objects are just there for programmatic access to certain features and controls of these objects. There are data members which are private and hidden as well as Cinema4D facilities which act upon them beyond a plugin classes reach. For instance, objects like Mmaterial and Opolygon are not plugin extensions of BaseMaterial and BaseObject, but fully supported objects within the interface. This support is not made available to a plugin object. But, if you find a clever way around this, we'd all be listening! 
3. Well, yes, Init() is always called when the object is created, but whether multiple Init()s are instantiating multiple same (as in indistinguishable copies replaceing one another) objects is the question. Init() in itself doesn't instantiate. That is done by the constructor. But, as I said, if you are instantiating anything within the Init() method (and not checking for previous instantiation), you will get multiples (and possibly memory leaks to boot).
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/03/2005 at 10:54, xxxxxxxx wrote:
2. Okay, I didn't take that into account;-) So, to rephrase it: it's possible to extend the SDK-classes of C4D-objects, but this extension will only be visible within the plugin itself.
And yes, if I find something I will surely write it here;-)
3. Hmm, but that faces me with a slight problem concerning my project. There I have several own Tags and an Object. And after creation from the menu they should register with a manager which is implemented as a SceneHook. But when I now store there in the manager the pointer to the TagData / ObjectData plugin-instances would it mean that after an Init()-call, the stored pointers reference to wrong instance, since the objects have been instantiated again.
Dani -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 16/03/2005 at 12:33, xxxxxxxx wrote:
2. Yes, to some extent. And what that means is that the functionality that makes the C4D object work is inaccessible by both your derived object and C4D. It is even possible that implementing certain virtual methods in your plugin will override those used by and necessary for the C4D object. You can get the 'pretty' GUI by including the .res for the base type in your .res file, but it will be dangerously nonfunctional.
3. Nope. Init() only initializes the data members of the XXData class.
From the start here, you first declared and defined a global RegisterXXPlugin() method which was called from your PluginStart(). This registers the new plugin type for use. This just tells Cinema4D how to make instances of your plugin (note that you explicitly tell it the Alloc() method).
Then a user selects your plugin object type to be added to a Document. The first thing that happens is that your plugin's Alloc() method is called which invokes the constructor (whether explicit to your XXData or implicit from what it is derived - BaseData). Cinema4D allocates and constructs the 'wrapper' PluginXX automatically which represents the plugin object.
Now, Init() is called for the XXData to initialize data members. As we have noted, this is done several times at first and may be called again later. You still have the same XXData instance in memory. You pass this to your SceneHook for registration. If the XXData is registering itself with the SceneHook, you are literally passing 'this' as the instance. If you are passing 'this' from XXData.Init(), it will still be the same 'this'.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 06:08, xxxxxxxx wrote:
While still waiting for someone (Mikael?) to answer my own questions from monday, like others, here is something i found out about your Init() question:
The undo-chain is realized by creating new instances of your object. This means a copy of your object is created via alloc() and then the init() function for the new instance is called. The new instance will hold the undo-information, meaning your original instance is now changed. this happens with every change of data of your object.
greetings
Peter -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 09:53, xxxxxxxx wrote:
This makes sense and would explain the Init()-CopyTo() calls made beyond the initial instantiation. But it does not explain four successive Init()-CopyTo() calls on an instantiation.
For instance, you call:
myPtr = (MyPlugin* )gNew PluginXX::Alloc(type);or create an instance of your plugin object in a usual way and you get the following sequence of calls:
Init() Init() CopyTo() Init() CopyTo() Init() CopyTo() Init() CopyTo()This is pulled right off of the Console Window for the addition of one of my shaders to a Material.
There are three instantiations that are unexplained. Mostly anyway. My guess is document caching is causing these extra calls.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 11:00, xxxxxxxx wrote:
Quote: Originally posted by kuroyume0161 on 23 March 2005
>
> * * *
>
> This makes sense and would explain the Init()-CopyTo() calls made beyond the initial instantiation. But it does not explain four successive Init()-CopyTo() calls on an instantiation.
>
> For instance, you call:
>
>\> myPtr = (MyPlugin* )gNew PluginXX::Alloc(type); \>>
> OOps. this looks to me like doing the job of allocation twice because Alloc() creates a new instance and gNew does the same, so its not a surprise to me you get more than one inits().
>
> Try leaving the gNew and look whats happening. At least my own source works well this way.
>
> greetings
>
> -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 11:45, xxxxxxxx wrote:
Nope, that gNew doesn't belong there.
I started typing on a class but went for a plugin alloc(). That doesn't change the results in the Console Window. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 12:28, xxxxxxxx wrote:
Hello Peter,
thanks for your answer.
Unfortenately, I don't have one for your question, Im just too new to the SDK;-)
This undo-thing makes it definitely clear now, why the inits get called all the time when you change an attribute of your object. Well, it doesn't make programming easier, when you have to handle all these undo-inits().
Dani -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 23/03/2005 at 12:40, xxxxxxxx wrote:
You don't have to handle them. Just make sure that the Init() method initializes and Free() frees any allocated objects not added to a document. The undos and caches are automatic when done with user interaction. Otherwise, the facilities for creating undos and caches exist in the SDK (BaseDocument.StartUndo/AddUndo/EndUndo/Undo/Redo, etc.).
You'll note that, as I had forgotten, whenever you render, a copy of the document is made for the rendering process. So, Cinema4D does alot of copying which always involves calls to Init().