Corona Renderer for Cinema 4D
Corona Renderer for Cinema 4D

jwiede

Gold Supporter
  • Content count

    517
  • Joined

  • Last visited

  • Days Won

    1

jwiede last won the day on September 5 2016

jwiede had the most liked content!

Community Reputation

22 Excellent

About jwiede

  • Rank
    Respected community member.
  • Birthday

Profile Information

  • First Name
    John
  • Last Name
    W
  • C4D Ver
    18 Studio
  • Location
    San Jose, CA USA

Recent Profile Visitors

1,994 profile views
  1. I use it, but on Mac, and as you note, the problem doesn't occur there.
  2. Yep, that actually worked, thanks for the suggestion!
  3. You're talking about setting it for one or two really "thick" segments and let it randomly populate a surface? That's viable, and I'll give it a try, but it lacks the "spatial awareness" about breaking up rectangles the way Greebler did (and also doesn't really provide for using libraries of greebles to populate. Hmm.
  4. As it seems quite clear Kuroyume (R. Templeton's company/site) isn't coming back, has anyone found any reasonably-equivalent replacements for their "Greebler" product? I have or don't need replacements for most of the other products, but cannot find a decent C4D Greebler-type plugin that supports libraries, etc. for population. I'm kind of desperate for a replacement, even considering writing my own at this point, but first wanted to check and see whether anyone else knew of any alternatives? Thanks!
  5. My big gripe with X-Frog is that emails either never get answered, or if they are ever answered, take weeks to months to get a reply. I purchased "5.3 for R17" (which became 5.4 for R17), and though I should have received 5.4 (for R17) as a result, never did. Now Xfrog is on 5.5 and I can't get any sort of reply whether an upgrade is needed or not in my case w.r.t. 5.5 and R18. Very frustrating. I've sent emails to just about every xfrog-related email address I can find (including admin@xfrog.com), to no avail.
  6. Yep, looks great! UVPaint just keeps getting better and better!
  7. W.r.t. the poll, I should note the answer I provided was in the context of a Mac version being available.
  8. Any word on when a Mac version might be available? If you need someone with a Mac and dev toolchain to help, plz PM me.
  9. Zblur2 and EdgeShade are both excellent tools, and it is great news that Chris made them available for everyone! Thanks Chris!
  10. I've also been using the 3.3/3.4 beta for some months now, and I'm quite impressed with the (substantial) improvements over the prior (1.8/1.9) version of VrayForC4D. VrayForC4D is (finally) getting very, very close to full parity with ChaosGroup's "main" Vray implementations on Max and Maya, and the general pace of VrayForC4D development has improved substantially. The LAUBlab team have migrated VrayForC4D to the latest Vray core from ChaosGroup, and on top of all the other feature benefits, doing so means VrayForC4D now has viable interoperability with other Vray implementations. I find the new version of Vray (CPU) to be generally faster, more flexible, and substantially easier to "tune" and configure. The denoiser is a welcome addition, and can substantially reduce overall render time requirements. The VrayRT (GPU) engine, though still limited in certain ways, is about as capable on C4D as either Max or Maya for the most part. If your scene fits within the limitations, the performance benefits VrayRT provides are nearly worth the price of the upgrade by itself. The complete list of added and improved features in VrayForC4D is quite lengthy (see here). I'm very satisfied with all the work the LAUBlab folks have put into VrayForC4D, it has definitely paid off for them in VrayForC4D 3.4. I upgraded as soon as I could based on my beta experiences, and am very glad I did so.
  11. The Cactus3D.com website is now just returning a "Not authorized to view" message, which doesn't bode particularly well for the plugins. None of my customer emails since Dan's passing yielded any reply.
  12. As (somewhat) more specific examples of what I mean: The CD FBX IO plugin offered deeper ability to customize certain aspects of how takes were imported/exported, etc. compared to the "native" C4D (hereafter just C4D) FBX IO support. The various CD CA plugins offered certain configurations of IK, morphs, constraints, tuning of skinning behaviors, etc. which lack direct equivalents in the C4D CA tools. This is about breadth/depth of articulation and control, as well as maintaining interoperability with MB (and Maya). The CD Symmetry Tools plugin enabled/automted creating/editing morphs and rig elements using symmetry in ways that lack equivalently-efficient workflows using C4D CA elements. Far from a complete list, but these three should serve to initiate the discussion.
  13. It's sad and unfortunate, but the complete lack of news/response since Dan's passing regarding the future of Cactus Dan's plugins suggests they're off-market for good (even Dan's site seems to have disappeared). Barring something changing on that front, it seems like C4D now has a significant "functionality hole" in CA tech as a result. The CD plugins were notable in their enabling of an end-to-end Maya/MB-"familiar" CA workflow in C4D. They also offered "depth of functionality" in a couple CA aspects where C4D's native solutions lack similar depth/configurability. While native C4D CA tools improved greatly in last few years, there are still coverage deficiencies in C4D's CA toolset and CA interoperability which (until recently) were addressed by the CD plugins. I would very much like to know if MAXON has any short-term plans to specifically address the functionality deficit left by the CD plugins, and/or further modernize/bolster C4D's native CA support in short-term to bolster C4D<->Maya/MB CA interoperability?
  14. It's more accurate to say nMP* ('Trashcan') has restrictions on form-factor and power that nobody but Apple currently seems interested in supporting. It's quite feasible that other cards with similar thermal and power characteristics as the Dx00s currently used could easily be OEM/third-party modified to meet the nMP slot requirements, it just hasn't happened yet. If enough nMP are sold, it might. *: Personally I think the nMP's days are numbered. I know many think Apple is backing away from desktop, to them I'll just point out that Apple's hiring does not appear to support that argument. I believe Apple do understand that nMP aside, they still need something more akin to the prior MacPro, in terms of a workstation-class, decently-expandable chassis, and will address that situation in a year or two. Time will tell. They gave the Cube every chance as well, but it eventually went away nonetheless.
  15. That's not accurate. My MacPro5,1 has a non-Mac-flashed 980ti, and while it creates certain limitations w.r.t. boot screen controls, it functions perfectly fine as a day-to-day graphics card (once booted, there's no difference). I'm running the usual Nvidia web drivers -- which, btw, continue to be updated, as do the Mac CUDA support, so Nvidia clearly is continuing to implement and release some Mac drivers. It is true there are no Pascal drivers for Mac, yet. Because both Apple and Nvidia are required to make changes to enable a new NV family, and because the Pascals came right as Sierra (10.12) was nearing release, I tend to believe Apple just didn't have enough time to test in order to feel comfortable enabling Pascal. It also seems likely Pascal support has now become negotiation leverage between Apple and Nvidia in their discussions.