Maxon Developers Maxon Developers
    • Documentation
      • Cinema 4D Python API
      • Cinema 4D C++ API
      • Cineware API
      • ZBrush Python API
      • ZBrush GoZ API
      • Code Examples on Github
    • Forum
    • Downloads
    • Support
      • Support Procedures
      • Registered Developer Program
      • Plugin IDs
      • Contact Us
    • Categories
      • Overview
      • News & Information
      • Cinema 4D SDK Support
      • Cineware SDK Support
      • ZBrush 4D SDK Support
      • Bugs
      • General Talk
    • Recent
    • Tags
    • Users
    • Login

    GetVirtualObjects() and textures

    Scheduled Pinned Locked Moved SDK Help
    3 Posts 0 Posters 280 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H Offline
      Helper
      last edited by

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

      On 21/08/2009 at 15:52, xxxxxxxx wrote:

      User Information:
      Cinema 4D Version:   R10-R11 
      Platform:   Windows  ;   Mac OSX  ; 
      Language(s) :     C++  ;

      ---------
      I'm having a bit of a rough time keeping the Texture tags' Materials on objects returned through GetVirtualObjects(). There is way too much code to post an example, so I'll explain as best as possible.

      My Generator plugin uses a library of objects which exist in the same document. If I simply clone the library objects and insert them into a Null object which is part of what is returned by GetVirtualObjects(), they retain their Texture tag material links. But then the user gets the joy of hundreds of objects (thousands, millions - literally, I'm doing a multi-threaded generator!) when they make it editable (or as part of the cache for rendering and such). In order to 'organize' that I've been connecting them into one conglomerate polygon object using SendModelingCommand(MCOMMAND_JOIN) with a temporary document containing a Null object under which they are all childed.

      Now, this retains the Texture tags (etc.) but the Material links are broken thereafter. Since this conglomerate can be a mix of many different library objects it would be impossible for me to reconnect them without explicit information (which is lost after the connect obviously).

      It seems that doing the connect in this temporary document is enough to break the links. Would it be advisable to copy the Materials (temporarily for the connect call) into this document in hopes that the links will remain? Or will the Texturetag<->Material links need to be temporarily stored so as to be reestablished after the connect?

      Thanks,

      1 Reply Last reply Reply Quote 0
      • H Offline
        Helper
        last edited by

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

        On 21/08/2009 at 16:06, xxxxxxxx wrote:

        I don't if this helps in your case but check the MarkMaterials structure and the MSG_MULTI_MARKMATERIALS message description in the SDK docu. It is used to duplicate materials and update the links if you for instance copy generators with internal material links.

        cheers,
        Matthias

        1 Reply Last reply Reply Quote 0
        • H Offline
          Helper
          last edited by

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

          On 24/08/2009 at 12:55, xxxxxxxx wrote:

          No idea about the MarkMaterials structure but what worked was this:

          Since the cloned objects are returned individually (childed to a Null object) and these retain the proper Material links, an AtomArray is filled with the Materials from them before MCOMMAND_JOIN. Then they are relinked afterwards on the result to reduced Texture tags (duplicates removed). Works perfectly.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post