Nodevember

#1

This is a heads up for Cycles4D users who may be interested in Nodevember a Blender community instigated Twitter hashtag where users are showcasing their procedural shading skills.

Many users are sharing their node setups as images and blend files so you should have no problem recreating in Cycles4D. There are some amazing setups on display that make me want to up my nodal shading skillz.

Each day has a different theme, today’s Reptile and yesterday’s was Snow and Ice. They’ve done Tornado and Lava shaders earlier too.

Even if you’re not a Cycles4D user there’s inspiration and techniques to borrow for the renderer you do use.

Search for #nodevember and #nodevember2019

Some good accounts to follow:
@nodevemberIO
@chiu_hans
@100drips
@simonthommes
@faaaaark
@bayultra

#2

Posting this because it’s insane.

If Insydium featured this stuff they could drive more customers to Cycles4D.

#3

Hi,
I’m amazed too. There are so many inspiringly smart people in the Blender world. It’s just fun to watch them.
Cycles and Eevee work just like my brain works. Everything is pretty straight forward and logic.

cheers

celke

#4

I wasn’t all that impressed with Cycles4D when I tried several years ago. But…

Blender’s Cycles is having a lot of performance tweaks added which should speed up rendering and not just with RTX hardware. I would expect these tweaks will trickle through to Cycles4D.

I have been testing Blender Cycles with the Intel denoiser and I’m amazed by the quality and if you just use the denoiser to get rid of fine noise it’s stable enough for animations. The render times are not a million miles away from Redshift for a similar quality.

If there are Cycles4D users here get all over to #nodevember2019 as there’s some serious knowledge being dropped.

#5

Yes, in the beginning Cycles was slow and rough on the edges. But I always liked the concept of the Open Shading Language, which was introduced with Blender 2.65.
At the current pace of development, Cycles will be one of the top renderers in the near future.

cheers

celke

#6

There’s no doubt we’re living in a golden age of 3rd party renderers, there’s something for everyone CPU or GPU.

Redshift had a very big lead on performance because their own CUDA based tracing code was head and shoulders faster than anyone else’s. Redshift barely gets any improvement with RTX hardware which is testament to what great code they have.

With RTX and the Intel denoiser it has meant other renderers, like Cycles, catching up to Redshift. I’m using the Intel denoiser like the Redshift adaptive sampler just to clean up the last few percent of noise.

Cycles4D users might not know about E-Cycles, this is a highly optimised version of Cycles developed by a 3rd party which is nearly 2x as fast as the standard Cycles in Blender. These optimisations will be added to the internal Blender build in due course, they’re running a year behind E-Cycles to give the developer a chance to make some money from his work.

So with E-Cycles optimisations and RTX Cycles4D will be worth another look, it’s a lot cheaper than Redshift, virtually half the price and will in due course close the gap on Redshift’s speed. Knowing what I know now I would get Cycles4D instead of Redshift and have much better XP integration and save a few quid as well.

Here’s the E-Cycles doc’s to give you an idea what might come to Cycles4D in the future. I’m certainly not speaking for Insydium but the logical conclusion is if this is going into future Blender Cycles it’ll come to Cycles4D at some stage too. https://blendermarket.com/products/e-cycles/docs

#7

Cycles 4D is still rough, I had given up on it because some scenes crashed even before render, the IPR was really slow, and was very frustated about it. It has improved, but is not in the same league of Redshift / Arnold.

Sadly, e-cycles isnt available for C4D. And it also have some issues, not sure why the developer isn’t hired by Blender Foundation, though. Im using more Blender than C4D these days, but sometimes I miss the drag and drop nature of C4D that makes the workflow so damn fast, but right now -for me- modeling an artwork > motion graphics / everyday random crap, so im sticking with Blender.

As a personal note, if Maxon improves dramatically modeling, viewport speed enhancements, and overall performance, it should be the holy grail of 3D apps, sadly it doesnt seem they want that, and to be honest, the developers who are clear about their objectives, talk to the community often and have a developer blog of every week 2.8, 2.81 and 2.82 improvements, arent the ones from Maxon.

#8

Personally, I think Redshift is the more rough. Redshift is fast, it’s fast because it cheats and hopes the user won’t see its cheats in the renders.

SSS in Redshift is a sad joke, it’s awful. Until they get random walk SSS you’re best staying away from SSS in Redshift.

Despite the recent wins with the Blender Development Fund they are still poorly funded compared to the likes of Maxon. Ton wants 3rd parties to take more of lead in supporting the renderer development. He suggested the developer of E-Cycles approach Insydium but according to the developer himself they were not interested in hiring him. This is why he is selling E-Cycles.

I began the thread for Cycles4D users as Nodevember would be useful for them not to start another Blender vs Maxon thread. I tried to get a conversation going but I don’t think there are many Cycles4D users here, if there are they’re keeping quiet.

I’ve checked the Insydium Discord a few days ago and there’s no mention of Nodevember in the Cycles4D area. Insydium are missing a huge marketing opportunity.

If you’re reading this and you’re in two minds which GPU renderer to go for, have a serious look at Cycles4D.

#9

This am I was struggling making materials for a suturing animation using C4D materials but when I went the route of using my new Cycles 4D materials it was a breeze and they turned out great. I am becoming a Cycles 4D fanboy.

SSS is especially good which was important for tendons

#10

I’ve been watching the various nodevember posts pop up in my twitter timeline and Im seeing some very cool things.

I agree with infograph about SSS being dissapointing in RS. You can get acceptable results, but not usually comparable to Arnold or Cycles. Even the diffusion SSS setting in Arnold look better and results are easier to achieve.

The RS SSS settings dont really make much sense either compared to other engines. Having the Single scattering settings in RS confuses matters more.

FWIW here are some tests I did earlier in the year when I was getting started with RS and became frustrated with the SSS workflow.

Redshift SSS (lots of fiddling to get a halfway decent look.)

RS%20settings
RS settings.jpeg544x1266 78.5 KB
RS%20render
RS render.jpeg1920x1080 90.1 KB

Arnold Random Walk SSS. Longer render times of course, but good results. Just a slider, and some radius setting adjustments, Abut 15 seconds of tweaking.

arnold%20render
arnold render.jpeg1920x1080 88.4 KB
arnold%20settings
arnold settings.png674x893 99.9 KB

And then Cycles 4D. I havent played with it much, and this was my first time really diving in. I figured out the settings pretty quickly and the results were better than RS IMO.

Cycles4D%20render
Cycles4D render.jpeg1920x1080 75.2 KB
Cycles4D%20settings
Cycles4D settings.png500x744 82.5 KB

All this being said, I have seen very good SSS results in RS in the hands of artists more skilled than I.

#11

thanks for the answer, who knows? maybe I’ll give cycles 4D another shot, perhaps I missed some critical update. In the meantime, I dont even know why I have to pay maintenance to Insydium because this year they move forward XP develpment at snails pace.

#12

My biggest problem with Cycles is particles and the alpha channel. Perhaps I’m misunderstanding some settings but the alpha seemed to cut most of the particle information from the image. I had to drop back to the standard renderer at the last minute as it made acceptable images with transparency.

Arnold SSS is king but I’ve been able to get acceptable SSS with Redshift so far if you fiddle a bit with the settings. It may just be luck. That speed, though. We’ll probably switch to Arnold once their GPU renderer is in full force.

#13

I underrated Cycles4D a lot, now that I have spent time with Cycles I know how to optimise the rendering, e.g. dropping the bounces down to the absolute minimum is critical. For no change in image quality you can easily drop the render time by half.

The Intel denoiser has also helped close the gap between Cycles and Redshift, along with general Cyles optimisations and RTX support have closed the gap even further, probably to the point the difference is negligible. It’ll only be a matter of time before this filters through to Cycles4D.

My experience with the Redshift Optix denoiser is that it’s virtually useless and I’m not sure if the Intel denoiser is coming to Redshift, I can’t recall them saying it is.

@Troyan
My experience with Redshift SSS is that it’s incredibly fast if you use point-based SSS but it’s very unreliable in animation renders especially with geometry with varying thickness, like Joel’s examples above. Flickering with point-based SSS is a real problem so the only safe option is raytraced SSS which will kill your render times. I have 2x1080TIs, not top tier performance by any means but they handle 99% of the scenes I throw at them easily but I could never get a clean raytraced SSS render out of them in an acceptable time.

#14

Rendered this on my home game machine GTX 1060 in Redshift. It doesn’t have that sweet Arnold “look” but I’m not seeing the flickering issue. This is point based, no GI, no denoising. 30 seconds/frame. I don’t have any problem with this but maybe my eyes aren’t as trained? I did make sure that my local SSS sampling was set much higher than the Unified samples, so the Unified sampler isn’t dealing with SSS. You should always set your local samples higher than your unified samples. Unified samples should only be calculating AA and DOF mainly, if you don’t the Unified samples have to shoulder it. Could that be the flickering problem or what am I missing?

#15

I will say that I have yet to get anything SSS usable in Cycles, as much as I love Cycles. I must be misunderstanding something in there, like the scale? Dunno.

#16

I don’t have the motivation to recreate the SSS flickering, render it out and post it. I’ve seen it and it’s a regular report on the Redshift forums and the support advice is to use ray traced SSS and not point sample SSS for animation. If you don’t get it, great and I hope it doesn’t end up ruining a production render out of the blue when the flickering gods are annoyed.

I’ve been using Redshift for over 2 years I know how to set up the scene for rendering, spread the samples and how to use the unified sampler.

If you go beyond simple lighting I’m sure you’ll soon see I’m not talking out of my arse.

I searched for SSS Flickering in the RS forum and this lead to this example.

#17

Yeah, that’s pretty bad. Seems like the lighting in his example is as simple as it gets. Dunno, I have yet to see the flickering issue and hopefully don’t. I will sacrifice my dragon to them just in case and hope they are merciful ;).

#18

Here’s my scene and settings if this helps anyone. I’m betting my settings could be cranked down a bit and still get good quality.

#19

The issue with point based SSS is that the samples must have a smaller radius than the edge. The flickering is caused when a sample is missing the fine edge between frame.

In my scene I had fine vein like trails that tapered to a point, there were created with XP Tendrils so they were moving from frame to frame so the tips were flickering like the instagram video I posted. You can change the size of the samples but it’s impossible to create small enough point samples to match fine geometry.

The unified sampler does not help, nor do the SSS samples nor does increasing lighting samples.

It’s a limitation of point based SSS we have to be aware of and workaround.

#20

Ahhh! I’m working on a scene right now with blood vessels. I’ll give that a test tomorrow and pray :).