Talks about Blender Cycles

A place to talk about your 3d work, compositing, and Visual Effects. Because some people roll that way.

Talks about Blender Cycles

Postby Paul » Fri Feb 10, 2012 3:25 pm

Originally I was somewhat skeptical, and didn't think it'd even work, and that it would somehow take away the control I have with the internal render engine.
I'm using it for a commercial project, and it's pretty epic. It takes a little while to get used to the node based shader system, but it's worth it.

It's kinda ridiculous that my $110 gpu (a gtx 465) is now better for rendering than a $300 core i7 2600... not better bit a little, but better by 10x or so.

It puts all the little handy features at your fingertips instead of hiding them in endless scrolling menus.

I'm pretty excited about the project I'm working on.

I've figured out how to use an image of a treeline as a mask against a moon, and a moving plane to add displacement to the moon, so it looks like there is an atmosphere between the viewer and the moon.

Also, the in view port rendering is really really helpful.

Have any of y'all had any such success?
User avatar
Paul
 
Posts: 209
Joined: Fri Sep 02, 2011 8:52 pm
Location: 90W, 45N

Re: Talks about Blender Cycles

Postby chirpsalot » Mon Jun 04, 2012 9:48 pm

I just started messing with it a bit as I decided it had been a while since I had messed with anything blender related (like, 2.42b a while... Crazy changes since then! Safe to say blender is much MUCH improved).

I have messed with cycles a bit and I am fairly happy with it! I haven't done anything interesting with it, but it is a very nice little path-tracer built into blender, and it has some very nice results (and maybe some bugs, which may be features that I am unaware of).

Looks like it's a very promising new bit to blender.

And of course your GPU renders faster than your i7 ;). It's what it was built for, more or less. CPU's are actually pretty bad at computer graphics. A decent graphics card should run circles around a CPU for such tasks. Path-tracing is a very parallel algorithm by nature, and lends itself extremely well to being executed on a GPU. CPU's suck for this, and a lot of tasks in comparison now.
chirpsalot
 
Posts: 61
Joined: Sat Sep 17, 2011 5:05 pm

Re: Talks about Blender Cycles

Postby Ian » Thu Aug 16, 2012 1:48 pm

Eeeeyeah. I was super skeptical first. I've been working on Mango (now called, "Tears of Steel", the latest blender open movie project), and we're trying to do the whole thing with Cycles. When we started out, it was crazy-super difficult to actually get a good render. Fireflies all over the place, insane render times. It was a bit like the fluid sim. Checking YouTube, you see hundreds of videos of water pouring into wine glasses- and it works fine for demos like that- but if you try it on anything larger- good luck! Cycles was great at rendering out little glass trinkets and chessboards, but an actual environment? Nope! But we've finally figured out how to work with it artistically, and the developers have been working like crazy getting stuff optimized and smoothing out the workflow. By the time the project's done, it might actually be production ready :P

For about 2/3 of the project, I would go home at night and do a project in Blender Internal, just to feel good about CG again, but I'm finally to the point where I'm occasionally using it for Dynamo, and by the time we're done, it might actually be my renderer of choice. Maaayyyyybe.

That said, it definitely helps to have a render farm at your disposal if you're trying to do animation type stuff. E'gads. And it still doesn't do interiors all that great (Mango is almost all interiors!!) But it's getting there.

The biggest thing I had against it at first was that I couldn't use any of my old techniques- every single scene I had to poke at forever until I found something that worked. But stuff's gotten fast enough that my usual "colored ambient light and sun lamp (or 2)" thing works, and the light is behaving predictably (or, I've just learned more how to predict it? I dunno!) And fireflies hardly ever happen anymore!
User avatar
Ian
 
Posts: 72
Joined: Sat Sep 03, 2011 12:08 am

Re: Talks about Blender Cycles

Postby chirpsalot » Thu Aug 16, 2012 11:14 pm

Ian wrote:Eeeeyeah. I was super skeptical first. I've been working on Mango (now called, "Tears of Steel", the latest blender open movie project), and we're trying to do the whole thing with Cycles. When we started out, it was crazy-super difficult to actually get a good render. Fireflies all over the place, insane render times. It was a bit like the fluid sim. Checking YouTube, you see hundreds of videos of water pouring into wine glasses- and it works fine for demos like that- but if you try it on anything larger- good luck! Cycles was great at rendering out little glass trinkets and chessboards, but an actual environment? Nope! But we've finally figured out how to work with it artistically, and the developers have been working like crazy getting stuff optimized and smoothing out the workflow. By the time the project's done, it might actually be production ready :P

For about 2/3 of the project, I would go home at night and do a project in Blender Internal, just to feel good about CG again, but I'm finally to the point where I'm occasionally using it for Dynamo, and by the time we're done, it might actually be my renderer of choice. Maaayyyyybe.

That said, it definitely helps to have a render farm at your disposal if you're trying to do animation type stuff. E'gads. And it still doesn't do interiors all that great (Mango is almost all interiors!!) But it's getting there.

The biggest thing I had against it at first was that I couldn't use any of my old techniques- every single scene I had to poke at forever until I found something that worked. But stuff's gotten fast enough that my usual "colored ambient light and sun lamp (or 2)" thing works, and the light is behaving predictably (or, I've just learned more how to predict it? I dunno!) And fireflies hardly ever happen anymore!


Haha, I like the fluid simulation analogy. I don't think cycles actually falls into that category, but I can definitely see it having been teetering on the precipice of such a thing in the past. It's a path-tracer, though. As long as it is reasonably fast it WILL prove to be useful with blender, at least for still scenes. I am a bit skeptical of the results for an animation, at least a homebrew animation where you DON'T have access to a render farm - getting rid of all of the grain may be exceptionally painful for a complicated scene with a single small set of computers. It's definitely do-able, but you will likely have some extra "film grain" added unless you spend a lot of time on rendering the finished product - and nobody likes waiting to see their project (and eventually notice a small stupid mistake and having to re-render).

I used to not be much of a fan of path-tracers, but they have grown on me recently. Previously I preferred photon-mapping as a method of generating global illumination, but I think path-tracing has proven to be a better option for most things. You can bake more stuff with a photon map, and there are some things that can work a little nicer... The grain can be a bit easier to control, I think (though, really there are similar problems - you can just kind of blend everything into less harsh artifacts that might even prove to be more visually pleasing). Photon maps were also just kind of cool! I liked the idea, and still do...

Path-tracing definitely has some pretty big advantages, though. I think the biggest advantage is that they are so simple (basically you just shoot a ray into the scene, and shoot more rays to find illumination at surrounding sources to the point - you can make it a little more complicated by using bidirectional path tracing and metropolis light transport, but the principle remains the same)! They are easy to extend and mess with... The code can be very small and easy to read and understand. You don't *need* to implement a KD-Tree or something to get reasonable results with a path-tracer (well, you will still need a space partitioning data structure for the scene's geometry... I think Blender still uses octrees for that? Octrees are pretty swell... You will probably want to implement a KD-Tree for the photon map in order to find nearest neighbouring photons to any spot in the scene - it's not that complicated, but it is an extra layer of icky). From the little bit that I have played with cycles it looks like they are attempting to make it fairly extensible and robust. You can relatively easily modify the "shaders" that are executed during the rendering, and it is laid out in a manner which artists might be able to understand and learn to use relatively quickly. I haven't messed with it too much, but if it works how I think it should... It should be pretty darn flexible, and give the artist a fair bit of control if necessary, in a manner which is relatively easy to understand. Which is awesome!

Path tracers also kind of look awesome by default... They happen to give a nice solution to the rendering equation and as a result simulate light pretty darn accurately! The only problem is that you get a fair amount of grain and "fireflies" sometimes, at least with small render times.

Of course the grain and fireflies can kind of be dealt with... You can just render with different seeds and blend the images together, for instance... That should work decently... Maybe blender will have a feature to do this automagically in the future? I am sure there are probably people way smarter than myself working on cycles, and they probably know of some fancier tricks to solve these problems!

Switching between the renderers will suck initially, though. There is probably no doubt about that... Particularly if you are used to how illumination worked in the old one, and dealing with that. I think the biggest problem I noticed was the inconsistencies between the light sources in the internal renderer and cycles? The regular light sources kind of sucked in cycles, but using geometry which emits light worked really well... I probably just don't know how to use it!

I am surprised that you have found that cycles is sub-par for rendering interiors, though. Path tracers excel at rendering interiors - it's kind of what they are best at, I thought. Rendering an outdoor scene should be worse? Well, actually... The interior scene should render better in cycles than internal, I would have thought. What is so bad about internals with cycles? Are you getting too much grain? Dark patches (can happen with sharp corners, sometimes it just becomes really unlikely to hit these patches with light, so you end up with slightly darker patches that look a bit odd)? Does the lighting just work differently than you are used to, or is crummy in other ways?

Just wondering! Of course, you are probably looking at it from more of an artistic perspective than I am. Whereas I am like "it simulates light better, therefore better?"... Which isn't always the case for artistic purposes. In fact, often I think it may even be a bit of a hinderance, depending on what you want to do.
chirpsalot
 
Posts: 61
Joined: Sat Sep 17, 2011 5:05 pm

Re: Talks about Blender Cycles

Postby The First Cib » Mon Aug 20, 2012 4:10 pm

I played with it for a week or so. I was really excited at first, the live render and the look of the light was awesome. But I have an ATI graphics card which parentally isn't supported so all the advantage of the supposed "lightning fact render times" is not there for me at all, cycles is just about the slowest thing on the planet for me, I haven't tested it but with my current set up I would guess that the Blender internal renderer is 2x faster for me right now. Also, I can't stand the rainy look it gives, it seems that no mater how long I render it just looks like garbage, the little weird grain pixels from the light just wont go away and are UGLY in video... Maybe that is a side effect of having to render with the CPU? Not sure.

Cycles looks crazy promising, I just hope that they come out with ATI card support soon.
User avatar
The First Cib
 
Posts: 45
Joined: Mon Mar 05, 2012 5:59 pm
Location: Alberta, Canada

Re: Talks about Blender Cycles

Postby The First Cib » Mon Aug 20, 2012 4:11 pm

I should read before I post :)

Those things are called fireflies?
Ian wrote:But we've finally figured out how to work with it artistically
Tell me more!
User avatar
The First Cib
 
Posts: 45
Joined: Mon Mar 05, 2012 5:59 pm
Location: Alberta, Canada

Re: Talks about Blender Cycles

Postby Paul » Mon Aug 20, 2012 8:17 pm

I just noticed we've got a new member!! Welcome Ian Hubert!!!

I was able to smack this project together using cycles early last spring, and finish it up in about 2 weeks including rendering, on my computer and two friend's computers. No problems with fireflies, except on shiny treasure, so I rendered that in a separate pass for 800 laps and stuck it on the scene which rendered in 25 or 50 laps.
viewtopic.php?f=10&t=55

I try to do most of my stuff in cycles, because it's really handy to have a realtime lighting preview, faster rendering, and stuff like that.

I've mainly been able to avoid fireflies by limiting caustics if I can, and glossy stuff, and super bright lights and high numbers of lights, and I've maybe once used the clamp feature that clips any pixels above a certain brightness.

I'm interested to see how y'all do on tears of steel in terms of realism and such. You should put a firefly into a scene and see if people see it. (the bug, not the render artifact =) )
User avatar
Paul
 
Posts: 209
Joined: Fri Sep 02, 2011 8:52 pm
Location: 90W, 45N

Re: Talks about Blender Cycles

Postby chirpsalot » Fri Aug 24, 2012 7:54 pm

The First Cib wrote:I played with it for a week or so. I was really excited at first, the live render and the look of the light was awesome. But I have an ATI graphics card which parentally isn't supported so all the advantage of the supposed "lightning fact render times" is not there for me at all, cycles is just about the slowest thing on the planet for me, I haven't tested it but with my current set up I would guess that the Blender internal renderer is 2x faster for me right now. Also, I can't stand the rainy look it gives, it seems that no mater how long I render it just looks like garbage, the little weird grain pixels from the light just wont go away and are UGLY in video... Maybe that is a side effect of having to render with the CPU? Not sure.

Cycles looks crazy promising, I just hope that they come out with ATI card support soon.


Yeah... It's a little weird that they managed to have an Nvidia CUDA version, and now an OpenCL version that mostly only works with Nvidia. I can imagine that's frustrating for a lot of people :\. Hopefully the OpenCL implementations kind of stabilize over time such that the OpenCL kernels and other guff are more portable between implementations. I find it strange that it apparently won't work on AMD cards...

Actually, what card do you have Cib? If it's an actual ATI card it might be too old to work with it at all in the future. Only moderately new cards support OpenCL 1.1 (well, a card that's a few years old is probably fine).

Hopefully it all works out for you in the end.

Paul wrote:I just noticed we've got a new member!! Welcome Ian Hubert!!!

I was able to smack this project together using cycles early last spring, and finish it up in about 2 weeks including rendering, on my computer and two friend's computers. No problems with fireflies, except on shiny treasure, so I rendered that in a separate pass for 800 laps and stuck it on the scene which rendered in 25 or 50 laps.
viewtopic.php?f=10&t=55

I try to do most of my stuff in cycles, because it's really handy to have a realtime lighting preview, faster rendering, and stuff like that.

I've mainly been able to avoid fireflies by limiting caustics if I can, and glossy stuff, and super bright lights and high numbers of lights, and I've maybe once used the clamp feature that clips any pixels above a certain brightness.

I'm interested to see how y'all do on tears of steel in terms of realism and such. You should put a firefly into a scene and see if people see it. (the bug, not the render artifact =) )


Pffff, yeah. Who is this Ian guy even :P?

Cool! It's nice to hear about some of the workarounds for the issues with Cycles - I haven't had the time to mess with it too much (never really could model all that terribly well... I got decent at it, but it has been a while... Takes a lot of time, blargh). It's good to know that there is a clamp feature, though!

I really hope Cycles keeps getting cooler. It is going to be awesome for Blender if it can keep up the pace. Kind of cool "watching" more artsy people mess with something like this in development. My renderers are usually these things with horrible interfaces that I tack together in a night or so. Generally it is like "pfff, artists! Nobody is going to use this anyway! No need to make it pretty!". Still. I should probably write a dinky little renderer and convince somebody to play around with it at some point. I think that would be a really cool thing to do! Fair bit of work, though. Going to be busy with school and stuff eventually. Bluh. I think I am going to attempt to be more focused on a project of sorts throughout the year, but that will probably fail miserably!
chirpsalot
 
Posts: 61
Joined: Sat Sep 17, 2011 5:05 pm

Re: Talks about Blender Cycles

Postby The First Cib » Sat Aug 25, 2012 10:15 pm

Paul wrote:I was able to smack this project together using cycles early last spring, and finish it up in about 2 weeks including rendering, on my computer and two friend's computers.
Oh, right I forgot about that one. You have some nice results in there, cant see any problems with the renders.

Paul wrote:I've mainly been able to avoid fireflies by limiting caustics if I can, and glossy stuff, and super bright lights and high numbers of lights, and I've maybe once used the clamp feature that clips any pixels above a certain brightness.
Limiting lights? :( I like lights. I agree with Chirps though, I am going to have to look up that clamp feature, sounds fantastically handy as I have basically had to be doing that manually in my composites with a luma key anyway.

chirpsalot wrote:Actually, what card do you have Cib? If it's an actual ATI card it might be too old to work with it at all in the future. Only moderately new cards support OpenCL 1.1 (well, a card that's a few years old is probably fine).

I have a 2010 iMac with a ATI Radeon HD 5670 512Mb card, so not amazing. Unfortunately because iMacs are built like laptops upgrading the card isn't a real practical option. Right now every mac runs an ATI Radeon card pretty much, so no mac user can really take advantage of cycles ATM. I am really looking forward to working with it though, lighting and texturing in live mode would be fantastic!
User avatar
The First Cib
 
Posts: 45
Joined: Mon Mar 05, 2012 5:59 pm
Location: Alberta, Canada

Re: Talks about Blender Cycles

Postby chirpsalot » Sun Aug 26, 2012 6:09 pm

The First Cib wrote:I have a 2010 iMac with a ATI Radeon HD 5670 512Mb card, so not amazing. Unfortunately because iMacs are built like laptops upgrading the card isn't a real practical option. Right now every mac runs an ATI Radeon card pretty much, so no mac user can really take advantage of cycles ATM. I am really looking forward to working with it though, lighting and texturing in live mode would be fantastic!


That's not too bad at all. Apple's OpenCL support is actually pretty much the best - so you have that going for you. Dunno what OpenCL version you will have, but there is a good chance it is 1.1 (and you will likely get a newer version if you upgrade the operating system at some point; I previously had OpenCL version 1.1, but now I have 1.2 with Mountain Lion). Once the Blender people get things together it is probably good to go! It really is a shame that cycles currently only works on one vendor's cards :\.

The First Cib wrote:Limiting lights? :( I like lights. I agree with Chirps though, I am going to have to look up that clamp feature, sounds fantastically handy as I have basically had to be doing that manually in my composites with a luma key anyway.


Limiting lights is probably just something you can work around artistically? I don't know. I really like having hundreds of glowy things waltzing about a scene. Still, the older fixed function OpenGL had a pretty harsh limit on how many lights you could have in a scene (you could always shade things using the CPU and have lightmaps to make up for it, but you had a limited amount of lighting that could be done straight on the GPU... Also it was Gouraud shading at best, gross)... You kind of had to switch between the lights you used in a scene - turning off those that were further away, or out of view.
chirpsalot
 
Posts: 61
Joined: Sat Sep 17, 2011 5:05 pm

Next

Return to 3d Work & Visual Effects

Who is online

Users browsing this forum: No registered users and 1 guest

cron