Jump to content

Cycles for C4D


Guest

Recommended Posts

9 hours ago, Zmotive said:

*hangs head in despair*

Just when I thought the OS X / OpenCL nightmare was passing. Should've guessed this would be the case.

Hopefully the CPU performance is top-notch. With so many features missing from the OpenCL side (and something I doubt Insydium can fix by themselves), not much reason to consider using that method.

It's not good is it?

I'm trying to decide how we go forward and the OpenCL Mac situation complicates things. We have VRay, love it and renders quickly on the CPU based render farm but there's no doubt rendering is heading to the GPU especially for projects the size we're now concentrating on i.e reasonably small. So I don't know whether to go eGPU with my Mac or build a custom PC to replace our render farm.

It'll be interesting to benchmark VRay up against Cycles in the typical scene types we work on before making a decision.

The other thing that complicates the decision is that Zync is coming to VRayForC4D which is affordable and likely better for our needs than investing in more hardware.

There is a bewildering amount of choice for rendering now...

Link to comment
8 hours ago, hvanderwegen said:

For what it is worth, back when I did my modeling in Cinema4d, 99% of the time I hit the shortcut key to convert to a mesh after adding an object. For polygonal modeling it is not very useful. A  non-destructive modifier stack is more valuable, in my opinion, and Blender does offer that. Text is also non-destructive and parametric.

Lightwave's and Modo's base objects aren't parametric either, as far as I am aware.

 

Each application has its strengths and missing features. Give and take.

 

 

Valid points on the modifier stack and typical modeling habits that people have. Even in motion graphics your point stands, not just hard-core modeling.  But the idea that you can add a primitive to a Blender scene and change the polygon density / overall detail prior to confirming the initial state of the primitive, but then can't go back a couple steps later and say "Whoa I had too many / not enough polygons to start with there, let me go back and adjust that before converting and duplicating", is a annoying limitation. You have to clear the mesh and recreate the primitive with different values until you get what you like.

Re Modo and Lightwave, no idea about the latter (never used it) but are you sure on the former? I thought Modo did have parametrics. Been a long time since I've used it though; I could be experiencing a memory error.

Definitely a game of tradeoffs when developing these apps though, that's a truth. And another truth is if you use one app for a long time you begin to think of that as "the right way", so there's some bias on my part, being that I so far have not dabbled much in other editors. Although I've seen enough cool stuff in Blender that I will continue to experiment with it periodically to build my skills there. Not a bad idea to have another powerful tool in the arsenal, especially if it's free.

 

3 hours ago, Cutman said:

It's not good is it?

I'm trying to decide how we go forward and the OpenCL Mac situation complicates things. We have VRay, love it and renders quickly on the CPU based render farm but there's no doubt rendering is heading to the GPU especially for projects the size we're now concentrating on i.e reasonably small. So I don't know whether to go eGPU with my Mac or build a custom PC to replace our render farm.

It'll be interesting to benchmark VRay up against Cycles in the typical scene types we work on before making a decision.

The other thing that complicates the decision is that Zync is coming to VRayForC4D which is affordable and likely better for our needs than investing in more hardware.

There is a bewildering amount of choice for rendering now...

Nope, definitely not good for people stuck with AMD GPUs. And as far as I can tell in Cycles the render option chosen impacts both the viewport and the final render. When you choose Cycles the viewport content changes / reflects the new render method. I don't think it's like C4D where everything in the viewport is GL-based (or GL- / MESA-based for R18), no matter what other features and settings are being used in other contexts. 

The ZYNC thing does look pretty slick on the final render side. Although I'm waiting for our Google overlords to take over everything one day.  I too have  been on the brink of going PC vs. waiting out a TB3 "pro Mac" + officially supported eGPU chassis. But there's been enough "wait and see" with MAXON, Otoy, Chaos, and Apple this summer that I'm hanging on a bit longer to see what ecosystem options I can reasonably piece together for next year and at what financial and opportunity costs.

Cycles for C4D is another "wait-and-see" recently added to the mix — a nice surprise though. Some things I'd like to see addressed in their newsletter this fall:

• General timeframe for release ("first / second half of 20___" is all I'm curious about, don't expect a specific target this early)

• What the plan is for OpenCL / AMD support, if they're just taking what Blender.org provides / not modifying that support.

• Confirm that the Cycles Live Render will operate completely independent of whatever is going on in the  R18 GL viewport or MESA viewport (if you're stuck on an AMD Mac). I can envision a scenario where if Cycles is relying on the CPU (because you have said Mac) and some element of Cycles' live viewport taps into the C4D display architecture, which would also then be using the CPU for MESA, you end up with performance hits. Maybe not / just speculation.

 

In the end the only scenario where Mac users have a bewildering choice of rendering tech is if they've already bought or built up a rig that has a CUDA card in it. Damnit, Apple.

Link to comment
16 hours ago, Zmotive said:

In the end the only scenario where Mac users have a bewildering choice of rendering tech is if they've already bought or built up a rig that has a CUDA card in it. Damnit, Apple.

The nMP could've been awesome if Apple hadn't screwed up OpenCL drivers and compiler and then got disinterested and just when developers are using it make a 90 degree turn and go down the Metal Compute route. It just asks too much of developers to keep trying to keep up with a moving target.

Link to comment

Yes it does.

Apple has done nothing but cause problems (instead of using their resources to solve them) in the Khronos space. GL, CL, you name it. They made a big noise when they adopted it, ran up against a hard problem or two sometime later, then quit. I also came to understand that the developer resources they provided were substandard compared to what Nvidia provided for CUDA developers. And then Apple switched APIs again. Naturally, one of their proprietary APIs that no one else on the planet is going to use for PCs or Linux or whatever.

Link to comment
12 minutes ago, Zmotive said:

 

 And then Apple switched APIs again. Naturally, one of their proprietary APIs that no one else on the planet is going to use for PCs or Linux or whatever.

The good news with Metal, DX12 and Mantle, er, I mean Vulkan they're all born out of the same/similar philosophy and I'm told if you write for one you can write for them all. All the APIs are tiny so the developers do most of the work outside of the API which should mean much more cross platform code is under their control, at least that's what I've read on GPU tech sites. Probably a huge simplification in reality.

Metal Compute, as far as I understand, is OpenCL 2.1 written in C++11 just to be different.

It'll be interesting to see which 3D app is the first to support the new APIs, MAXON? If the marketing is right audit makes it easier for developers to write cross platform code then a company like MAXON with such an even 50/50 split must sure be considering the new APIs.

Link to comment
8 hours ago, Cutman said:

The good news with Metal, DX12 and Mantle, er, I mean Vulkan they're all born out of the same/similar philosophy and I'm told if you write for one you can write for them all. All the APIs are tiny so the developers do most of the work outside of the API which should mean much more cross platform code is under their control, at least that's what I've read on GPU tech sites. Probably a huge simplification in reality.

Metal Compute, as far as I understand, is OpenCL 2.1 written in C++11 just to be different.

It'll be interesting to see which 3D app is the first to support the new APIs, MAXON? If the marketing is right audit makes it easier for developers to write cross platform code then a company like MAXON with such an even 50/50 split must sure be considering the new APIs.

 

I think it's a little different than that. From Apple's own description it's a new API they wrote and (for lack of a better word) layers built into it for OpenCL and OpenGL in order to bring backward compatibility. That was from last year's WWDC schpiel. I believe they made minor additions to Metal this year, addressing some of the missing features relevant to 3D work, but I don't know the details and haven't heard much fanfare from developers since WWDC. Nothing to give me hope Apple got it right.

Although Adobe did start adopting Metal in this most recent release of AE, so who the hell knows. Anything is possible.

Link to comment
Guest DamienP

I tried to replicate the dragon render in Blender Cycles with the C4D node setup on page one. It was not even close for me, Using an entirely different node setup, this is the closest I came to it. 

Dragon Test 2.png

Node setup.PNG

Link to comment

Blender has me scratching my head. Still tinkering with it the last few days when not working on other stuff. While the UI looks nicer than I anticipated and is somewhat more customizeable, the actual methods of interacting are a PITA compared to C4D. Props to MAXON for getting that right a long time ago.

Link to comment
  • 3 weeks later...
  • 2 weeks later...
×
×
  • Create New...

Copyright Core 4D © 2023 Powered by Invision Community