dast

Short answer: you can't. Cinema 4D is designed (as far as I know) to use a single shortcut for a single plugin. Before implementing the current toolsets via the middle ring, I researched possible solutions to provide multiple dials. One solution was to provide a command plugin per dial, which would allow users to define separate keyboard shortcuts per dial. This would also mean that the number of dials was predefined, as each dial would require a unique plugin ID obtained from MAXON. Furthermore, this would mean that the number of dials (thus toolsets) could not be created dynamically At that point, I assumed people would prefer having a single plugin, instead of one entry per dial, and be able to dynamically create the number of dials they wanted. As mentioned above, for each dial a separate plugin ID is required. I could provide 5, 10, 20 entries. Then someone comes along and requests 21 ;-) I would thus much more prefer a dynamic solution ... which I currently do not have. Let me sleep over it for a few nights, and I might come up with something. Nothing promised.

The free version of the plugin, available to download here at the C4DCafe, is not a demo version but has limited features. The fading in of the icons one by one is a limitation of this free 1.0 version. When you purchase the paid version (updated to 1.1), next to support you also obtain additional features such as the possibility to create multiple dials, as well as favorites per tool. This version does not have the limitation of fading in icons one by one. Features of the paid version are available in the demonstration video I provided a few posts back (https://www.c4dcafe.com/ipb/forums/topic/103440-dials-was-wheel-of-tools/?do=findComment&comment=687595)

A quick demonstration video has been added to the first post. It shows most of the available tools in action, hoping it provides an idea of the features available. I don't have demo versions of my plugins, except for Dials. While I understand people would like to try out to see if a plugin does fit one's workflow, it isn't always manageable to make a demo version without crippling the plugin. EDIT: since plugin is available free of charge, no need for a demo version anymore

I am planning to create some videos to demonstrate the available features of this plugin. Intended for beginners, as this is whom this plugin was focused for. However, since EasyUV is heavily based on Seamilar, the basic UV editing (move/rotate/scale) of points, edges, polygons and island is similar. You could thus check out the video created for Seamilar to get an idea how these tools are used. The original move, rotate and scale philosophy from the native core UV tools was kept. As such, these 3 operations use 3 different tools, each with their icon and Attribute Manager settings. In a future update I intend to merge these 3 tools into a single tool, as I myself have encountered scenarios where it would optimize the workflow in a great way having this single transform tool instead of the current separate actions. As said, this is future, so this should not be taken into account for your current decision making to use this plugin or not. As for the EasyUV tag versus the regular UVW tag: note that the EasyUV tag only stores the information related to seams and UV islands, the actual UV editing does happen on the regular UVW tag.

All I really needed was a way to render each separate icon with the same render settings, to the same folder, but with different filenames. In the end I only figured out a solution by creating a Take for each icon, manually naming the Take by the icon name it represents, and then using the Take name in the render settings. But then I figured I could step it up a little, as some icons were created using a perspective camera, while others with a simple top-down camera. With the Takes system, I could easily specify which camera to use. In the "old" days, I would have manually selected the appropriate camera, select the appropriate objects, hide the not-needed objects, change the output name in the render settings ... and press render. Rinse and repeat for all icons. It was a quick set up with Takes, but I need to use it more often in order to create some "muscle memory", as I already have forgotten how to do it. OK ... back on topic now.

EasyUV is ready and finalized. Available for Cinema 4D R16 upto R20, Windows and macOS. Available at Tools & Pixels For a limited period of time: introductory price of 15 euros.

Yes, the Python itself isn't the issue here. So the actual Python code could be shared to version before R17 ... when you copy/paste the entire code. Files containing Python code seem to be problematic when loaded into older versions. Although I haven't checked if Python scripts created in R17+ do have the same issue as the Python nodes in Xpresso or the Python tag. The hex editor was just a way to visualize the text data. Newline and carriage returns (ASCII characters 10 and 13, or 0a and 0d in hex) aren't visible in a regular text editor.

I understand you might think so, but NO, definitely not. From the start I assumed it was something related to how R16 did read or interpret the Python text data, triggered by the fact that you resolved the issue by retyping the first line of code. I went a little further, and just randomly added an empty line or a comment line anywhere in the Python code. This also - surprisingly - fixed the issue. I mean "surprisingly" in the sense that it is not code related. Went even further and saved the working version in R16 and compared both original and resaved text data (using Winmerge utility). This mentioned that both files used different carriage returns ... so I looked at both data in an hex viewer. This shows all characters in the text data, even the non-readable ones. Apparently, the R16 Python editor does use a different carriage return than R20. I assume that the switch between carriage return types was done at time of R17, since I can load the R20 Python in R19, R18 and R17 without issues. It's only R16 (and probably earlier versions) that show this problem. Anyway, there's not really something you can do about all this ... unfortunately. The only thing the user with an older version needs to do, is to force the Python editor to modify the carriage return by slightly modifying the content.

Not at all. What I noticed: when you import the more complex file into R16 and select the Python node, you can see C4D has trouble interpreting the Python content correctly. The Attribute Manager shows the Python code, but the second line - a comment line - is not correctly color coded. If you then open the Python Editor it does show correct color coding for that second line. By the way, I tested on R16.050 not sure what has been fixed since the version you have running, being R16.011 Checked the MAXON website, but they seem to only go back to R17 for available updates, so cannot really see if any Python interpreter or editor related fixes had been introduced between our two versions of R16. All I know is that this particular issue doesn't seem to be related to PEBKAC Wondering if the issue would be fixed without retyping the first line. Import the scene file, open Python Editor, press compile ... and check if the yellow title bar disappears. Just wondering.

I created a simple scene only containing a null, added an xpresso tag and in Xpresso created a python node. Left all default, saved the scene file and opened it in R19, R18, R17, R16. All version opened the file without problems. So, I can't really confirm the problem. From your first screenshot (with the error) it seems the first line looks like "import c4d, math". Shouldn't that read "import c4d.math", with a dot instead of comma? Is it maybe a locale thing istead, where decimal point in text is interpreted differently on different OS versions? Just thinking out loud.

I have been using Substance Painter for a while now. Purchased version 1 when it came out, and upgraded over the years. And while we don't actually know what the future will bring, I honestly don't have a good feeling about this merge with Adobe. I am still using an old perpetual license of Photoshop CS5.1, and wouldn't mind staying behind with Substance Painter 2.x if they ever intend to go subscription only. But as said, no idea how things will evolve ...

With all my other plugins converted to R20, and temporarily out of the way before I start adding new features, I wanted to spent some time on finalizing EasyUV. As a first step I wanted to get the plugin working for R16-R19. Step 2 would be to port it to macOS. And final two steps would be to port it to R20 on Windows, then to R20 on macOS. Quite some work ahead. For Seamilar I had created all icons in a drawing application. But this time around I wanted to model them, as I figured it would be faster to adjust. As well as reuse and interchange parts between icons. And it allowed my to finally learn how to use the Takes system inside Cinema 4D. As each icon is a different Take I could "simply" set up all the Takes and then perform a single "Render Takes". And all would be output as 32x32 bitmaps at the press of a single button, for perspective or top-view cameras. The scattering of the icons is maybe not that artistic, but I found it nice looking ... and it helped to take my mind of from all the coding I had been doing all day long. With step 1 completed it's time to take the next one.

Dials and my other plugins are now available for R20, see blog post below

PolyGnome and my other plugins are now available for R20, see blog post below

Seamilar and my other plugins are now available for R20, see blog post below If you are looking for an easier way to do UV mapping than using the native tools, and don't need all the features available in Seamilar, you might want to look at EasyUV instead (coming soon). It is based on Seamilar but has less features, and as such will be less expensive.

Still an hour and a quarter to go, but we're off to bed ... Happy New Year.

Finalized version 1.1 and wrote the documentation. An early Christmas present sent out to those having donated ... check your e-mails. Others will need to wait for the official release, in a few weeks.

Thanks! Scripts are available in the download section now.

I wanted to send you a PM, but apparently you're not able to receive messages (inbox full ?), as such let me pass the message this way: Hi Hrvoje, I have been using a few scripts over the years, and moving to R20 I noticed I missed some. Apparently, these were COFFEE scripts, so I took the time to rewrite these in Python. Now, I was about to upload them to the C4DCafe's download section for others benefit, but noticed these original scripts were named VP_Reset Position and VP_Reset Rotation. I figured these must have come from a Vertex Pusher tutorial I had purchased in the past. So, before uploading the converted Python versions, I 'd first like to ask if it is OK with you to upload these. I don't want to take credit for these, as they are simply derived from your original work.

Still need to figure things out before making the official announcement, but probably all my plugins being ported to R20 will be available from 1st January 2019. As I planned a less feature rich sibling of Seamilar (announced as EasyUV), I am also planning a less feature sibling of PolyGnome. It's a little early now (and still haven't figured out an appropriate name), but I soon hope to be able to announce this "EasyMeshblender".

Thank you for your interest in PolyGnome. R20 version of the plugin is completed, and will be available to the public starting from 1st January 2019.

Also remember that when hovering over the favorite "dot" in the dial, the description/info of the favorite is displayed in the status bar (even user has entered description/info). I agree that colors are difficult to memorize when having tenfold of favorites, but I haven't found a better way ... yet.

If you create a favorite with "mixed" settings, one checkbox on another off ... what would the restriction be? Besides, why restrict? The user can adjust the colors the way s/he wants. It is up to the user to define his/her favorite, which values are on/off, positive/negative ... So, choose your color the way you want. I also figure everyone has their own methodology of what colors best fit with what settings. Who am I to restrict anything?

I am in the process of finalizing the update of Dials. Still a few minor changes to do, and then the usual building on macOS. As well as porting to R20 (both Windows and Mac). New in this update are : - drag-n-drop for adding tools - favorites (via drag-n-drop) - support for multiple tool sets While the plugin was originally designed to work for tools only, a side effect of its design is that other parts of Cinema 4D can be dragged to the tool sets as well. Scripts, primitives, deformers, ... And these can be executed from the dials just like the regular tools. Unfortunately, favorites currently only work for tools. Maybe in future updates this can be extended as well.

Stacking UV islands is on my todo list ... next to so many other features. Cannot promise when any of these will become available in future update(s).