writing an exporter-plugin

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/07/2003 at 13:44, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.100 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
I was unable to find some useful information for writing an Exporter in C++, that exports C4D- Meshes in my own format.
Here are some questions related to the topic:
- what Headers do I have to include, what libs to link?
- what suffix should the dll have (assuming the plugin must be a dll ) ? Is it *.dlx. *.abc or something else?  
- how can I get a basic understanding of the SDK? I am an experienced 3D-programmer and wrote several exporters for MAX, but for me it is impossible to get a clue how the C4D-SDK works. Are there any well commented Code-Samples, a simple Tutorial, a How-To or something? A VC++-Plugin for creating C4D-Plugin-Projects would be great. I just need a point to start and a direction to go. A 2000- classes reference is not what I mean.     
Thanks in advance!

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/07/2003 at 06:49, xxxxxxxx wrote:

Yes, you *are* missing something...
Have a look in the plugins folder and open the cinema4dsdk project. It contains many examples of how to create plugins. Make a copy and remove everything you don't need to create a plugin of your own.
(Yeah, doing everything by the reference only would be impossible. You need the stub provided by the SDK.)

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/07/2003 at 09:19, xxxxxxxx wrote:

Thanks!
The STLSaverData-Sample helped a lot. but I still have some questions left : 
- how can I get uv-Coords?
- how can I get the hierarchical Info for a scene? The GeListNode- Object seems to be organized in an "4D-List".  If I got it right, that list supports only hierarchies with only one Child. My Grafics-man says, C4D can do more than that :-).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 21/07/2003 at 15:01, xxxxxxxx wrote:

- They are contained in UVW tags on each object. Use BaseObject::GetTag(Tuvw, i) and cast to UVWTag.
- As you say, the list is 4D. Use GetUp()/GetDown() to go one way and GetNext()/GetPred() to go the other way. (I suggest you make a small test hierarchy and try these functions to see what they do.)

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/07/2003 at 07:25, xxxxxxxx wrote:

ok,
I want to write a small Test-Plugin to understand the way the 4D-List works. My problem is getting the name of each node.
This little piece of Code just delivers the type, not a name:

    
    
    
    
     
    
    
    
    
      
    String GetTypeName(Atom* op)  
    {  
        if (op)  
        {  
          AutoAlloc<Description> desc;   
       if (!desc) return String();  
            
       if (!op->GetDescription(desc,0)) return String();  
            
         
       const BaseContainer* bc = desc->GetParameterI(DESCID_ROOT,NULL);  
          if (bc) return bc->GetString(DESC_SHORT_NAME); //DESC_NAME);  
        }  
          
     
    
    
    
    
     return String(); // Fehler  
    }  
    

Another problem:
including <Windows.h> makes problems. Any solutions?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/07/2003 at 15:50, xxxxxxxx wrote:

Hello,
1. you should at first try to learn at least the basics of Cinema 4D to understand what those objects are.
2. You should access the child classes that are inherited from GeListNode. Those classes do represent each object within Cinema 4D. For example a cube is usually accessed via the BaseObject class.
Example:
Objects in the Object Manager are at least BaseObjects and are always (of course if you create them yourself and you haven´t inserted them, they are not) in a scene (scene represented by BaseDocument class). So you can access for example the first object in the Object Manager by BaseDocument::GetFirstObject(). 
This function will return a pointer to the object. You can now get to all other objects in the scene (actually in the Object Manager) by using firstobject->GetNext() to get the next parent in the scene hierarchy level, or firstobject->GetDown() to get the first child of the firstobject and so on.
I would highly recommend getting to know Cinema 4D a bit...otherwise it will be hard to reasonably write a plugin.
3. including windows.h was already discussed here in the forum, please use the search function to find the corresponding thread.
Hope that helps
Best
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 03:25, xxxxxxxx wrote:

Thanks for your help, but I know all of this.
I started my search to find the name of an object in the SDK- Description of the BaseObject. I found nothing there and thought, ok perhaps its a property, look in the tags. That leeds  me to class BaseTag. No Name or ID or anything there. Ok, next try, perhaps it is in some Parent-class of BaseObject. I tried Atom and all or nearly all classes the way up to BaseObject and found nothing.
I think in the meantime I have a good understanding of the way the SDK works, but I still have problems squeezing information out of it. 
I just want to get the string that is shown in the  Objectmanager for each Object. I would be logical to put it in BaseObject or a related class, but there is nothig.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 03:29, xxxxxxxx wrote:

GetName()???

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 04:02, xxxxxxxx wrote:

Thx, my fault.
relating Windows.h: There seems to be no real solution, except separating Windows and C4D- Code and that is no solution. Will there be a fix in the near future?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 04:10, xxxxxxxx wrote:

relating Windows.h: There seems to be no real solution, except separating Windows and C4D- Code and that is no solution. Will there be a fix in the near future?
You can also create a c4dwindows.h but must take care of your defines etc. Please see the thread that the search result returns (windows.h and set to message body).
I doubt there will be a "fix". The SDK must maintain Plattform independency and I don´t think this belongs into this section. But I don´t know really. Probably Mikael can give you more information on this.
Best
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 05:02, xxxxxxxx wrote:

Hmm, ok.
Most of the errors are coming from redefined types. Why don´t you use your own types in the SDK (e.g. C4_DWORD,  C4D_COLOR_BACKGROUND) like everyone else does it?
ok, perhaps there are also other problems.. but they should be yours, not mine ;-).

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 05:09, xxxxxxxx wrote:

Most of the errors are coming from redefined types. Why don´t you use your own types in the SDK (e.g. C4_DWORD,  C4D_COLOR_BACKGROUND) like everyone else does it?
I guess for the easy C++ compatibility. But I´m not really sure.
ok, perhaps there are also other problems.. but they should be yours, not mine ;-).
They shouldn´t be mine either I´m not at MAXON.
Best
Samir

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 11:36, xxxxxxxx wrote:

A better question is why there are so many #defines, so few typedefs and so few namespaces. And this can be asked both of the SDK and the Windows API. I guess for both the answer is "historical reasons". I agree that it's a PITA.
However, my experience is that a carefully crafted set of #undef and #define can fix this. I just verified it by adding this snipped to the top of Atom.cpp and then using Beep() from the Windows API.

    
    
    #include <windows.h>  
    #undef COLOR_BACKGROUND  
    #undef CreateDialog  
    #define Polygon CPolygon  
    #undef min  
    #undef max
    
    
    
    
    //
    
    
    
    
    #include "c4d.h"  
    #include "c4d_symbols.h"

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 25/07/2003 at 13:39, xxxxxxxx wrote:

If you just want to call a few WINAPI- Functions this might be a way to go. But if you want to use lots of own code or embed parts of a game-engine into C4D, it´s impossible.
Is it really so hard to recraft the C4D-Api or just a matter of huge text-replacement?  if the latter is the case, it is easy to write tools for that purpose.
Thanks anyway.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 26/07/2003 at 07:45, xxxxxxxx wrote:

Perhaps a future version of the C4D API could move to namespaces, so that the type would be for example C4D::LONG instead. But that still wouldn't help the windows.h namespace pollution, since the #defines in there wouldn't respect our namespaces.
However, it's hard to respond to your claim that using the game engine is impossible without knowing more about what the collisions are. Usually there's a workaround for problems like these that make them merely hard but not impossible. Btw, have you tried defining WINDOWS_EXTRA_LEAN_AND_MEAN to reduce the pollution?
Rebuilding the C4D API would indeed be some work, and definitely not something I would trust an automatic replacement to do. Basically you would have to replace all #defines with either a) typedef, b) const LONG x =, c) enum or d) inline, depending on the context. Then you could wrap all headers in a C4D namespace. Finally you would hope that Microsoft decides to do the same in their next version of Windows...
Also, as noted before, it's always possible to avoid these issues completely by separating the C4D and the external code into different modules, and use only common types in the headers.
Good luck whatever route you choose!