Hi Index, thanks for reaching out us. I confirm that the development is on supporting glTF is continuing. Stay tuned! Best, R

thank you so much!!

@PluginStudent Thank you.

@r_gigante While doing some code cleanup to add new features to a plugin, I noticed some comments regarding this particular topic. The comment mentioned the need for a workaround since the Blit() functionality on Windows was faulty. Problem with Blit() and MultipassBitmap still occurs after switching to Visual Studio 2017, Windows 10, running R20.059

I don't think there are any official "tools". But the docs describe how to handle unicode (Dialog Layout The encoding is 7-bit ASCII with other characters encoded as \uHHHH. For example 'Natürlich' is written 'Nat\u00fcrlich'. Byte-order marks are not used.

@m_magalhaes Thank you

Hi @blastframe unfortunately for the moment is not possible to implement its own logger in python. However, you could use any existing loggers. Here an example that writes into the Application (Default) Logger. import maxon txt = "My Wonderfull Text" defaultLogger = maxon.Loggers.Default() defaultLogger.Write(maxon.TARGETAUDIENCE.ALL, txt, maxon.MAXON_SOURCE_LOCATION(1), maxon.WRITEMETA.DEFAULT) Note that the print simply reroutes to the Python logger. But it can be useful to directly use the logger to write if you pass the write meta maxon.WRITEMETA.UI_SYNC_DRAW this way you can force a redraw of the console (slower) after each print, this can be used to avoid the limitation mentioned in the second part of this post. Cheers, Maxime

@PluginStudent Thanks for the idea of how to solve this! I was doing what you described before posting my example, but probably making it too complicated. The documentation for the Link gadget describes the pointer LINKBOX_ACCEPT_MESSAGE_ACCEPT as 'A pointer to a boolean value. Set this value to true to accept the object.' so that sounded like what I needed. I've rewritten the approach you described and have it seemingly working.

hi, must be monday, sorry, the 21.207 IS the current last public version (and after another test, the bug is definitely there). It's already out the next update we can't tell what and when. Cheers, Manuel

Great, thank you.

hello, I'will consider this thread as solved tomorrow if you have nothing to add Cheers, Manuel

Since this topic is older than a week I marked is as closed, but feel free to reopen it if you have further questions. Cheers, Maxime

Hi @chakuew0, plugincafe is only a support for Cinema 4D API and SDK, and I don't see in any way how your question is related to the API, but more an issue within Cinema 4D. So please contact the Cinema 4D support for all no related API questions in this page. Cheers, Maxime.

Thanks, it's good to know that there are internal functionalities actually using these flags!

Thank you so much! This helps me a lot with the understanding of what was going on. I am digging back into my work on this today and will follow up with your advice.

@zipit Hi, Thank you so much.

@m_adam Thank you for the clarification and the code example, Maxime!

Hi @JohnThomas thanks for the follow-up. I see the point, but when you're dealing with uniform splines you've also to consider the number of intermediate points you're using to approximate the natural spline. With a natural parametrization even with a low number of points the vertexes position returned from SplineHelp::GetPosition() are accurate, whilst with a uniform parametrization you get higher accuracy as long as you increase the number of points. See the data below, where first coordinate is the position returned by the SplineHelp::GetPosition and the second coordinate is returned by quering the points vector PointsObject::GetPointR() Natural_4 [4, 2123.461, BEZIER, 1] 0 [0/0], 0.000[0.000] --> (200.000,0.000,0.000) -- (200.000,0.000,0.000) 1 [17/0], 0.250[530.865] --> (0.000,700.000,0.000) -- (0.000,700.000,0.000) 2 [34/0], 0.500[1061.731] --> (-200.000,0.000,0.000) -- (-200.000,0.000,0.000) 3 [51/0], 0.750[1592.596] --> (0.000,-200.000,0.000) -- (0.000,-200.000,0.000) Uniform_4 [4, 2107.332, BEZIER, 2] 0 [0/0], 0.000[0.000] --> (200.000,0.000,0.000) -- (200.000,0.000,0.000) 1 [7/0], 0.350[737.566] --> (4.370,699.695,0.000) --> (0.000,700.000,0.000) 2 [14/0], 0.700[1475.132] --> (-199.849,8.692,0.000) -- (-200.000,0.000,0.000) 3 [17/0], 0.850[1791.232] --> (-4.394,-199.953,0.000) -- (0.000,-200.000,0.000) Uniform_16 [4, 2107.332, BEZIER, 2] 0 [0/0], 0.000[0.000] --> (200.000,0.000,0.000) -- (200.000,0.000,0.000) 1 [7/0], 0.350[737.566] --> (4.370,699.695,0.000) -- (0.000,700.000,0.000) 2 [14/0], 0.700[1475.132] --> (-199.849,8.692,0.000) -- (-200.000,0.000,0.000) 3 [17/0], 0.850[1791.232] --> (-4.394,-199.953,0.000) -- (0.000,-200.000,0.000) Uniform_128 [4, 2124.555, BEZIER, 2] 0 [0/0], 0.000[0.000] --> (200.000,0.000,0.000) -- (200.000,0.000,0.000) 1 [182/0], 0.353[749.359] --> (-1.373,699.970,0.000) -- (0.000,700.000,0.000) 2 [363/0], 0.703[1494.600] --> (-199.996,1.279,0.000) -- (-200.000,0.000,0.000) 3 [440/0], 0.853[1811.636] --> (1.380,-199.995,0.000) -- (0.000,-200.000,0.000) If no further help is needed please don't forget to set the thread as Solved. Cheers, R

hello, I've lookied into the live selection tool and internally it's using GetPixelInfoPolygon, or the equivalent for point and edges. You also have Get<xxx>PixelBuffer where <xxx> is Point, Edge or Polygon. That return the internal buffer constructed inside the Init function of the ViewportSelect Class. pixelBuffer[ width*y + x] will give you the right pixel on that buffer. Sorry to have missed those functions. Cheers, Manuel

thanks to all of you, got it working with axisstate.x = int(doc.GetData(c4d.DOCUMENTSETTINGS_GENERAL).GetBool(c4d.DOCUMENT_STATEX)) kind regards mogh