when will Cycles have volume material integration??

I was just wondering since blender developement team decided to stop developing the internal render engine, whether sometime they would be putting smoke simulations/volumetrics into the cycles render engine. Because trying to put fire/flames from a blender render scene into a cycles render scene is a pain, hard and usually doesn’t look real

Cycles roadmap

realistically,probably not until the last quarter of 2013,depending on who gets involved.

“Next would be a focus on Volumetrics and Hair. It’s probably still going to take some 4 months until I start to work on them, though there are already other developers working on both, so we might see them released earlier.”

An excerpt from the roadmap that marcoG_ita posted. It’s from November and with some luck we might get there sooner than later… Then again, for Blenderheads it will feel like an eternity…

I’ve found it usually works pretty well. You just need to remember to include some lights in the Cycles scene where the center of the flame is. Adding some bloom/glow usually helps sell the effect.

There’s a decent chance now that hair functionality might wind up in trunk for 2.66 or even by the end of the year (though possibly as part of the ‘experimental’ feature set as it gets worked on). Check the hair thread in News & Chat for progress, the developer already has the patch a good ways toward being production-ready.

As for Volumetrics, a developer under the name Storm_st already has a fully working volumetrics patch for Cycles, however, he notes that they take a long time to render which as a result lead him off on a tangent that may also lead to the inclusion of bidirectional/metropolis sampling like in Luxrender.

@Ace_Dragon I’ve seen the test renders with the Cycles hair and I must say I’m impressed and can’t wait to get my hands on it to try it (I’m on a Mac, and since I have no builder skill I’m without a version to try it).

Personally I would prefer a slow render instead of no volumetrics, but since we still have BI, we still have options and as you said. LuxRender too is available, even though it’s resets the bar pretty high for having a clue what to do and how to use it.

Grab this then: http://graphicall.org/1022

Oh my goodness! Thanks a bunch Ninja J! That certainlay made my day. I know what I’ll be tinkering for the next week.
This is like Christmas, but actually getting what you wished for! :slight_smile:

Grab this OSXbuild, a new one


And every newer than r53373 where commitment happened.
Just enable under render properties / feature set / experimental

Yeah I saw that! It’s going to be hard to get things done in the upcoming days. Thanks for the heads up though. When ever the Volume patch in Cycles gets implemented I’m thinking I might not return to the BI at all…

Hey Michalis, I have AhnandHaraja’s 53402 with Strand Rendering and OSL. I switched over to experimental and looked around, but I’m not seeing anything about volumetrics. I don’t see anything in Addons in UserPrefs either.
Can you think what I might be missing?
Or is it just in the OSX builds so far…?

they’re not talking about volumetrics, they’re talking about hair

Uh. Oh. Sorry, I haven’t really been watching this thread. I’ve been too busy playing with hair myself! :slight_smile:
Since this is the “Volume” thread, I thought they were saying that there were experimental versions of a working volume patch out in some builds…
:spin:
The hair is coming along well. It will be cool when volume starts working in Cycles too.
But no pressure, Storm St! :slight_smile:

Some scenes with volume things really need bidirectional (or at least light tracer) to converge faster, for example light beams nearby light source in foggy atmosphere. But if one need other cases, i can separate patch by removing all bidir and spectral things. Maybe even better, cherry pick and rewrite already working functions like Woodcock delta tracker, main H-G BRDF, then refactor questionable part (longer Cranly-Patterson rotation vector in Sobol random generator, as current is too small, only 2 dimensions, and produce bad “clustering” artifacts). Also extra random congruential generator for inner loop, it looks ugly, maybe there are other solutions exist.

Big performance related issue is how to get volume material for some arbitrary point, for example how to detect where is camera, what volume media around camera. I use simple heuristic, fire ray from point with random direction and use some logic to get material based on even/odd status of backfacing in all intersection points along ray, assuming all objects are closed. It not fast as require many ray/scene tests every pixel. For static camera it can be cached, but how to make it fast for motion blurred camera or lights in case of bidirectional or light tracer. Transparent trick (checkbox “shadow”) does not play well with my patch, but i think it can be resolved later. Anisotropic can be optimized, and still lack of Mitsuba trick to make guaranteed probability to sample volume in case some triangle intersection found.

Also, i completely ignore OSL, it volume model is different and not bidirectional friendly, in fact i hate OSL more and more with every new day, as render passes, that make work with shaders not easy as original Cycles :slight_smile: . All that must be resolved before inclusion.

I believe Brecht has mentioned before that he plans to eventually look at what you’ve done so far and try to separate out the volume code from the rest of the patch, so splitting it out into its own patch would make his job a lot easier when it comes time to implement volumetrics.

As for performance, I believe most engines like BI use a sort of light cache that is done in a pre-processing stage which allows for much faster rendering at the expense of accuracy (since it would then be an approximation).

One of the main questions would be this, how would Brecht allow Cycles to have a similar level of performance without messing with pre-processing steps, something which he will also need to look at for SSS.

So is this topic of volumetrics going to be in full development and integration around blender 2.69?

So is this topic of volumetrics going to be in full development and integration around blender 2.69?

Check the roadmap. Should get some attention in 2.69, yes.

The volumentric in BI is good acctualy and it would be okey… ut there is one big problem with Z value that it dosn’t take it from the volume material but from the domain with makes it totaly an usefull.