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
    • Unread
    • Recent
    • Tags
    • Users
    • Login

    The NodeMaterial is a temporary class ?

    Cinema 4D SDK
    2
    3
    356
    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.
    • B
      bentraje
      last edited by

      In the C++ documentation, it says

      The NodeMaterial is a temporary class, introduced in order to provide access to the node system. In the future this class will be deprecated, as most of the use cases are covered by the BaseList2D and the maxon::NimbusBaseInterface.

      Does this mean if we build our pipeline around this NodeMaterial object all our code will be useless later on?

      Why does it have to be temporary? Why not make it permanent? I thought this was already part of the "new" core.

      1 Reply Last reply Reply Quote 0
      • M
        m_adam
        last edited by

        Hi @bentraje, as you know, Nodes have been present in Cinema for a few versions.
        There was an early version of this API that allowed some renderer developers to access the Nodes.
        This way they could implement them, but more importantly, we could also get feedback on their needs.

        Since S24 aims to not break API compatibility and some external renderers depends on this NodeMaterial, this class is still present.

        However, the scope of the NodeMaterial is to retrieve the graph belonging to a NimbusRef for a given BaseMaterial.
        But this is also the purpose of BaseList2D::GetNimbusRef()->GetGraph() but with the advantage of working for any BaseList2D and not just Material.

        In addition, there are still some features that are not available in BaseList2D, for example, BaseList2D::PrivateGetOrCreateNimbusRef does not act like NodeMaterial::AddGraph since Bl2D::PrivateGetOrCreateNimbusRef does not call the Creation function to set the initial state of a Graph.

        In the future, BaseList2D will have all the functionality of NodeMaterial, which is why it is temporary.

        If you build your pipeline around this NodeMaterial, you will have to rewrite this part.
        But honestly, NodeMaterial is just the street to get to the building (the graph), if we remove that street, you'll just get another one (BaseList2D::GetNimbusRef).

        Cheers,
        Maxime.

        MAXON SDK Specialist

        Development Blog, MAXON Registered Developer

        1 Reply Last reply Reply Quote 0
        • B
          bentraje
          last edited by

          Hi @m_adam

          Thanks for the response. Although just a personal sentiment, it is a bit disappointing having to wait 3 years for the actual API only to find out that it will be irrelevant in the next few releases.

          Anyhow, will close this thread.

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