Jump to content

C4DS

Monthly Contributor
  • Content Count

    849
  • Joined

  • Last visited

  • Days Won

    31

Everything posted by C4DS

  1. Another point to make, if you're looking into putting the VSTs on a different SSD from the operating system, then remember that the writing isn't that important, but the reading is. You'll probably only write once, read many in terms of sample library usage. As such, it might be worthwhile to have a cheaper Samsung 4TB QVO for your sample libraries. I didn't want to go that route since I only have a single drive in the laptop, and operating system then need to share the same disk as the sample libraries, so I also need to pay attention for the writing speed. Looking at the vi-control.net forums (that's where I get my mustard) 64GB seems to be quite "low" amount of RAM these days, when it comes to large templates in DAW. Just make sure to allow room for expansion, if you go 64GB. Don't use up all your memory banks.
  2. If you have a sh*tload of virtual instruments (sampled based I assume) you might consider a larger SSD, Or an extra 2TB SSD to replace the HDD, and put your samples on there. I have just replaced my 500GB SSD in the laptop with a Crucial 2TB to hold all sample libraries, which I "less than occasionally" use to create video backgrounds ... have about 1.2 TB of VIs. I know, in my case it's a waste of the space, since I maybe use the VIs once a year ... if not less (figure of speech).
  3. With the documentation having been completed, I went ahead and focused on bringing every version of Seamilar in sync. Over the past year new features had been added to the plugin. Due to differences in SDK for the different releases of Cinema4D this required that updates to the plugin needed to be written for every separate release. As such, usually the latest available release of Cinema4D (r20) was supported for testing purposes and for quick user-required updates. For the last 4 weeks I have been updating the implementation of the plugin for the older releases (R16 - R19). With that completed, it's now testing time. And if that goes well, I will port the updates to macOS (for R16 - R19). Since beginning of December (2019) I have encountered a few bugs in Cinema4D R21, which I have reported to MAXON. I still haven't heard back about possible work-arounds or future fixes. Existing customers will soon be provided with the updated version(s) of the plugin. If all goes well (and no further issues are encountered) this will be the last Seamilar 2 update ... before switching to Seamilar 3. This future version of the plugin already has its own thread on the forums. As this current thread has been running for a little over 3 years it is about time to get a rest ...
  4. C4DS

    PolyDup

    Yes, it will be on mesh level only. You select "source" polygons on a mesh and select "target" polygons on that same mesh to replicate the source polygons to. Not procedural, not cloner-like. Although, this procedural/cloner-like thing might be an idea for a different plugin: where you specify source and target polygons, and changes applied to the source (like move, rotate, scale, extrude, ...) gets also applied to the target ones. That might be a nice idea, but quite more complex to implement.
  5. C4DS

    PolyDup

    PolyDup (I am open for suggestion for a suitable name, as well as for icon, images, ...) Description: PolyDup is a tool plugin which allows to easily select part of a mesh and replace polygon(s) of the mesh with a duplicate of this part. The concept is the same as with PolyGnome, where you can replace polygon(s) of a mesh with predefined asset objects, allowing to construct meshes from parts. The difference with PolyDup is that you do not need to create asset objects. The selected part of the mesh will represent the asset. With this you will be able to easily duplicate parts of a mesh, without the need to model it more than once. Status: The plugin is still in its design phase. It will reuse the modelling engine from PolyGnome, so that part is basically available as is and will only need fine tuning for the new purpose of this plugin. While PolyGnome was a command (= "single-shot" action), this new PolyDup plugin will be a multiple action tool. Development of the plugin will be in Cinema4D R20 (Windows) and ported to other releases of Cinema4D, both Windows and macOS. Estimated Release Date: unknown Supported Cinema4D releases and platforms: R16-R21 Windows, macOS Price: unknown View full record
  6. PolyDup (I am open for suggestion for a suitable name, as well as for icon, images, ...) Description: PolyDup is a tool plugin which allows to easily select part of a mesh and replace polygon(s) of the mesh with a duplicate of this part. The concept is the same as with PolyGnome, where you can replace polygon(s) of a mesh with predefined asset objects, allowing to construct meshes from parts. The difference with PolyDup is that you do not need to create asset objects. The selected part of the mesh will represent the asset. With this you will be able to easily duplicate parts of a mesh, without the need to model it more than once. Status: The plugin is still in its design phase. It will reuse the modelling engine from PolyGnome, so that part is basically available as is and will only need fine tuning for the new purpose of this plugin. While PolyGnome was a command (= "single-shot" action), this new PolyDup plugin will be a multiple action tool. Development of the plugin will be in Cinema4D R20 (Windows) and ported to other releases of Cinema4D, both Windows and macOS. Estimated Release Date: unknown Supported Cinema4D releases and platforms: R16-R21 Windows, macOS Price: unknown
  7. C4DS

    ShowMe

    I used to have a thread about this plugin, but it apparently is archived and unaccessible for editing. With this new thread I'd like to continue providing a spot for discussing its features. More to come ... <placeholder>
  8. Ah ... I actually thought that was what you meant when I first read your question, but then I figured "who would want to know that?". That mouse mat has been a birthday present many many years ago ... custom made, still cherish it to this day. Unfortunately, sunlight has degraded the picture.
  9. A Logitech G600 mouse with 20 programmable buttons. I once thought it would enhance my workflow having all necessary shortcuts at the click of a button instead of using keyboard. It has 12 buttons on the side, the regular left and right mouse buttons, then an additional "pinky" mouse button at the far right. On top: a scroll wheel with down, left and right button actions, and two "mode" buttons in front of the scroll wheel. One of the mode buttons has a 3-cycle state, which allows to have a different set of actions for the buttons on the side. This allows to have up to 36 different actions for side buttons. I used to map tools and commands depending the layout I was in. It was heavily used when I still was doing 3D modeling and animation, but lost its use when I switched to plugin development, some years ago. The (quite useful) 3D mouse on the left isn't even connected anymore. Hasn't been for the last 3 years. Nowadays it is just sitting pretty, reminding me that someday I need to pick up 3D animation again ... It's a shame, but it is what it is.
  10. Just a quick set up of the extra screen. Now I can debug the plugin code on one screen, while working in Cinema4D on the main screen. No need to constantly swap application screens anymore. And that via a single USB (A) cable ... nice. I just don't have the room to fit 28" screens. And with these small monitor sizes I cannot justify for 4K screens. My old eyes already have difficulty reading text on HD screens, let alone 4K. Sure, you can scale up text and graphics ...
  11. Happy New Year. I ordered a portable monitor for my laptop (should be delivered any time now) ... doubling my resolution. That will be my one and only resolution for 2020.
  12. C4DS

    Seamilar 3

    I agree. Didn't expect this plugin to exist for so long, before being overruled by the updates in the native UV tools. It seems MAXON is finally ready to provide updated tools, looking at the recent tweet from the CEO. Looking forward to what these UV updates might be. Hope that these don't introduce even more issues than what MAXON did with the new GUI. Anyway, Seamilar has turned 3 earlier this month, maybe it's time for a new name for next version? The first and second iteration of the plugin were heavily based on the "seam" part of the unwrapping story. Hence the plugin's name. With the next version we'll focus more on the editing part of the story. Not neglecting the already available tools from the current version, but extending them. Adding more possibilities. Making it easier to use. Changing the small things that have a large impact. My only wish is that by then MAXON has fixed the issues in R21, so every plugin at least behaves as it does in previous releases. Anyway, let the new name roll in ... I am open for suggestions.
  13. For the past few months I have been updating my Seamilar and EasyUV plugins. I have been using my R20 development environment to research, design, implement, test, document (and so on, and so forth, and what have you), as this was the most comfortable for me to use after I had set up the environment after that particular version of Cinema 4D was released. And maybe also for this silly reason I still don't like R21. Call it personal preference or whatever, but using and looking at R21 still doesn't feel "home". But let's not disgress into that rabbit hole. With implementation finalized and thoroughly tested the next step of porting the code to previous releases of Cinema 4D as well as to R21 was completed end of November (2019). Each version of the plugin (both on Windows and macOS) was then tested to check for typos being introduced during the porting. This minor testing revealed no issues, except for some known drawing artifacts I had noticed back in the days when working on plugins on macOS for R18, and still continue to be displayed as such in the latest release. For some strange reasons when drawing seam terminator dots in the 3D Viewport these ended up being represented as small squares on macOs, while nicely represented by ellipses on Windows. As the Mac mini I was using for development did not contain a discrete graphic card, which my Windows machine did, the difference in graphical representation of the 3D Viewport on both machines was like night and day. Therefore, ever since I assumed this dot-drawing issue was related to the graphical capabilities of the Mac I was using. Unfortunately, when time came to test the R21 version I encountered an issue I hadn't seen before, and started looking into the R20 and previous versions of my plugin to check and see if I had overlooked something. I could not reproduce the problem with previous versions and decided to report the issue to MAXON SDK support. They confirmed the problem and created a bug report. While waiting on feedback from MAXON's developers I tried some things, hoping to find a workaround to the problem. While I couldn't find any solution I stumbled upon another issue, which I also reported and got confirmed as well. And if that wasn't enough I now also noticed the dot-drawing issue on the Windows version of R21, which I also reported. While I had a lot of mixed feelings about R21, and that after the whole auto-renewal of the MSA had left quite a strange taste in my mouth, these new issues definitely have further strained the already joyless R21 experience. As such I have decided to refrain from providing R21 versions of my plugins to new customers. At this point in time I still have no feedback from MAXON developers about the state of the issue, or a possible solution (be it as a Cinema4D fix, or as a workaround in my plugin). With the upcoming holiday season I also do not expect to get any information, let alone a solution, before January ... at the earliest. An update to EasyUV will be sent out soon to existing customers, and while the R21 version does still experience the aforementioned issues, effort has been made to reduce it as much as possible. Seamilar customers will be getting an update later on, as I am still finalizing the stacking feature.
  14. Maybe not exactly related, but I experience slow drawing response in custom views created in plugins. Have reported this to MAXON SDK, and it has been confirmed. A bug report was logged, but haven't received any further feedback. Not sure when a workaround or fix will be provided.
  15. I am usually at 120%, but when switching back to 100% all is OK. Going to 110% I notice that half of the area is accessible, half not. Meaning that it seems to only accept the 100% area, whatever scaling is used. With 120% the profile settings falls right outside of the 100% area. When at 110% it falls halfway outside. It seems to be related to a recent change (yesterday, or the day before), as in the past I have been using 120% for quite a while without issues.
  16. Not only the sign-in button is affected. When you're already signed in you cannot access your profile settings. It shares the same area as the sign-in button. Being a monthly contributor I don't have or see the ads, but still encounter the limitation.
  17. Finalizing the documentation for version 2.9.1 Update and more details coming soon ...
  18. Ok, now I understand what you mean. Unfortunately, I have no solution for that. Sorry!
  19. I do have some script/plugin that might help, but before I suggest any I would like to really understand what you need. What do you need to show, what do you need to hide? I understand that the dense geometry inhibits a clear view. But if you switch off polygon edges how are you able to select points or polygons if there is nothing to indicate where polygons or points are? How are you able to edit anything, if what you want to edit isn't visually defined? It would be as if blindfolded picking points and polygons, would it not? So, please explain how you would want the clutter of polygon edges to be shown or hidden, and still allow you to edit them?
  20. A new UV editor ("U haVe ...")? About time. Now I can finally stop adding features to Seamilar.
  21. C4DS

    EasyUV

    A few weeks ago, while preparing a tutorial about EasyUV and Seamilar, I discovered some bugs in the plugin and spent some time fixing them. As mentioned in other threads I am mainly working and developing with R20, as this feels the most comfortable. With bugs fixed in the R20 implementation, I then "simply" had to port the changes to previous version. This went fairly well, and testing of the R20 and previous releases indicated no further bugs (as far as I could tell). However, while porting the changes to R21 was not a problem either, testing revealed quite some surprises. I encountered two issues within the implementation of the new GUI in R21 and contacted MAXON SDK support about these. One of the problems was a performance hiccup, while the other was rather cosmetic, and I provided MAXON with sample code to reproduce both. The perfomance related one was confirmed, and I would be contacted later with possible workaround (if any). The other, in my eyes less important, hasn't yet been accepted nor rejected by MAXON. What I am trying to say is that while I do have a new version available for R16 - R20, I would rather wait to have a final response about the issues with R21 before releasing this 1.3 version of the plugin. I would prefer to release a single update containing changes for all supported Cinema 4D releases. Thanks for your patience. EDIT: As mentioned in the following blog post, version 1.3 of EasyUV will be provided to existing customers, without a proper fix for R21. https://www.c4dcafe.com/ipb/blogs/entry/601-the-post-r21-announcement-depression/?tab=comments#comment-518
  22. C4DS

    Seamilar 3

    Seamilar 2 is nearing a 3-year development birthday, having reached version 2.9 and with over 26000 views (see here) I guess it's time to turn the page, and start a new topic. I will refrain from going through the details again, but for the time being my main development version of Cinema 4D will be R20. With support for earlier releases, back to R16. As well as the latest R21 release. Both Windows and macOS are supported, for as long as possible. I will be looking into providing a final maintenance release as version 2.9x before jumping into designing its sequel: Seamilar 3 More news to follow ...
  23. Thanks for the reply. As far as I am concerned pre-R20 plugins already are separate projects with duplicate effort. Even with support for the classic API, separate implementation is needed for R20 plugins, as the code just cannot be shared. With the change in licensing and the CommandData even R21 plugins require to be a separate project. For some plugins projects can be combined into a single one for R16, as the resulting plugin remains compatible running in R17-R19. But for others, each release (R16, R17, R18, R19.) requires its dedicated project. For R20 all plugins share one R20 project (using the new project tool), for R21 also a separate project for all plugins. Then duplicate all this for Windows and macOS support. At best I have at least 6 projects per plugin, at most 12 projects for a single plugin. As for your last paragraph, I am not even going to consider that for now. Not having a subscription myself I will only be able to handle versions available for perpetual licenses. Besides, one can only handle appropriately when the situation is present. Knowing MAXON's policy they're not going to tell upfront which changes will break plugins. I know about the MAXON Registered Developer program, as I applied for it the moment it was announced, but have reclined to accept their single-direction NDA policy.
  24. Recently I had to upgrade my development machine in order to be able to install and run Cinema 4D R21, and develop plugins for it. Up to that point I was still using Windows 8.1 and happily running Cinema 4D R16 up to R20. In the past I had kept installers for all releases, both on Windows and macOS in order to occasionally have a clean start and reinstall the operating system, development environment and Cinema 4D. Or so I thought ... as it seems I am missing the installer for R17 on Windows, and the R16 installer on macOS. Additionally, when installing R16 on Windows it doesn't update to the latest version anymore since MAXON seems to have removed it from their servers. Luckily I now have also downloaded all updates for R17 and up. Still, I am missing some installers. I could start discussing with MAXON support or MAXON SDK support how to obtain an old installer, and/or updates. But knowing this might lead to a dead end, I was simply wondering how far back users would need plugin support? When I look through my personal plugin sales, I notice most users are R20, some R21. A very few have R19, and one or two are using R18 or R16. As my plugins were originally created for R16 and above, I intend to keep it this way ... except that with the current situation I will not be able to provide any new updates for R16 and R17. Hence the reason for the attached poll. How far back to you expect plugin updates to be available?
  25. Thanks for mentioning those plugins. I didn't want to chime in and blatantly do some self-promoting. When I first saw this discussion, my first thoughts went to the tutorials about the fuel tank. Couldn't find them with a search, although they have been brought up quite a few times in the past. I guess this might be due to a clean-up or change of the forums lately. Glad you provided the link to these, here once more. As for my plugins, I might do some quick introduction tutorial to show the usage in a worflow. I haven't done this yet, as I assume(d) users of the plugins knowing what they're doing, and are only looking for tools to speed up the process. This one really doesn't help in explaining the process, but it's a quick overview of the workflow I am used to: https://vimeo.com/237128529 If interested I will see what I can come up with to try and explain on a beginner level.

Latest Topics

Latest Comments

×
×
  • Create New...