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

    R12 - plugin conversion

    Scheduled Pinned Locked Moved SDK Help
    13 Posts 0 Posters 997 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 18/11/2010 at 07:28, xxxxxxxx wrote:

      Please post the code line of your array construction.

      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 18/11/2010 at 07:42, xxxxxxxx wrote:

        My array declaration is this:

        GeDynamicArray<Vector>defpos;

        in both versions, but in R12 is clearly double precision

        thank's

        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 18/11/2010 at 07:52, xxxxxxxx wrote:

          Originally posted by xxxxxxxx

          My array declaration is this:

          GeDynamicArray<Vector>defpos;

          in both versions, but in R12 is clearly double precision

          thank's

          Ah, I thought as much 🙂 Vector is defined as LVector in R12. If you don't want to convert to double precision you have to construct your array with SVector and use ReadSVector().

          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 18/11/2010 at 08:12, xxxxxxxx wrote:

            thank god. 🙂

            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 18/11/2010 at 08:16, xxxxxxxx wrote:

              Sorry but I don't understand!
              The problem is that in R12 to read a Vector struct from 11.5 scene (that is like SVector for R12), I used an SVector that then I convert in LVector using: ve.ToLV()

              see the example posted up (WRONG WAY CODE)

              But this doesn't work!
              I hope of being clear.

              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 18/11/2010 at 08:20, xxxxxxxx wrote:

                You need to use GeDynamicArray_<_svector_>_ to get the same as in R11.5. Oh wait, now I see what you mean. Right, it actually should still be correct to use ReadSVector when written WriteVector with 11.5 (which you say doesn´t work right?)

                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 18/11/2010 at 08:25, xxxxxxxx wrote:

                  Ok, I will do some tests.

                  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 18/11/2010 at 08:29, xxxxxxxx wrote:

                    Originally posted by xxxxxxxx

                    You need to use GeDynamicArray<SVector> to get the same as in R11.5.
                    Oh wait, now I see what you mean. Right, it actually should still be correct to use ReadSVector when written WriteVector with 11.5 (which you say doesn´t work right?)

                    Yes, the problem is that on reading I don't use the array vector directly, but I use a temporary var that is formatted like a SVector to conform the R11 struct!

                    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 18/11/2010 at 08:33, xxxxxxxx wrote:

                      Exactly as Matthias explains.  If you want to have R12<->R11- compatibility with binary files then you will need to remember type sizes.  I had fun when dealing with Real since it is equivalent to SReal in R12.  But Real in R12 is LReal (as can be seen if you hover over a variable in VC++). Same situation as Vector.

                      This is why I am an advocate for types by size (but we can keep our general types too!) unlike how it is with 'long' changing its size dependent upon the bit-width.  I want these standard types instead:

                      BYTE/UBYTE: 8-bits
                      WORD/UWORD: 16-bits
                      LONG/ULONG: 32-bits
                      LLONG/ULLONG: 64-bits
                      DLONG/UDLONG: 128-bits
                      etc.

                      The problem is no one codes to a standard like this.  They have WriteLong(LONG lv) and LONG can be 32, 64, 128, or whatever bits dependent upon various configurations.  Bad in my book.  Great for when you never read and write files (maybe).  Painful and minefield otherwise - whenever you need backward compatibility or support both 32-bit and 64-bit systems, for instance.

                      In other words, instead of changing the definition of a type name by system (like how int can be any one of many, many sizes dependent upon OS and bit-width - now that is a minefield and I never use int any longer), make type names that encode bit-size once and for all.  We are never going to have 3-bits or 54-bits.  Bit-widths are always a power of 2, starting at 8 (8, 16, 32, 64, 128, 256, 512, 1024, 2048, etc. etc.).  My mantra: make it explicit.  int isn't explicit - it is overly fluid.

                      I will disembark from my soap-box now. 😄

                      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 02/12/2010 at 22:21, xxxxxxxx wrote:

                        Amen, Brother Robert :).

                        I have actually run across SDK-type example code for reading/writing a proprietary 3D file-format (examples provided by the designer/author of the format) that had 'int' slathered all through it (in the structures being written/read). Needless to say, I sent him an e-mail on the subject :). Of course this format also used 16bit word values to store "number of polygons" and "number of vertices" values, so it wasn't exactly a modern/forward-thinking format.

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