Cycles: Experiment with cutout object
Needs ReviewPublic

Authored by Sergey Sharybin (sergey) on Dec 8 2016, 3:02 PM.

Details

Summary

The idea of this feature is to convert an object to some sort of portal for ray. This way we can to effects like object slicing which might be really handy for arch vis and some engineering visualizations.

here is an example:

Diff Detail

Repository
rB Blender
Branch
cycles_cutout_object
Build Status
Buildable 408
Build 408: arc lint + arc unit
Sergey Sharybin (sergey) retitled this revision from to Cycles: Experiment with cutout closure.Dec 8 2016, 3:02 PM
Sergey Sharybin (sergey) updated this object.

Great idea, seems rather easy and useful.

One addition that might really help is detecting whether the camera is inside a cutout object before rendering by tracing a ray towards infinity from it.
Of course, non-closed objects would still be a problem, but not much can be done there.

Also, it seems weird that Cutout is a closure, but it's applied whenever it is present without regard for weight or other closures. For me, it would therefore make more sense to have it as a object option instead of a shader.

Lastly, the counter works for this usecase, but it's pretty specific. We already have a volume stack, and I've got a (unpublished) patch for nested dielectrics using a stack that tracks refractions, so as a long-term solution it might be nicer to have a unified stack that tells which object you're in.

Indeed we should detect whether we're in cutout or not. Could work similarly to volume stack detection.

As for weight -- there's a TODO in the code about this ;)

Before digging into such things wouldn't mind if we review "bigger" aspect of the patch (whether it's osmething we want for upstream, whether we want it as a closure etc..).

Note for self: need to do volume_enter_exit for volume objects when inside of cutout object.

Idea and code looks good to me. :) Having this as a closure seems good, more intuitive than adding yet another UI checkbox to object/mesh data settings imo.

Just experimenting with proper fit of the node into the shader tree

Previously it was rather useless to be in th shader tree because
the ray was always transporting to through the cutout, now in the
cases when cutout it mixed with some other nodes we'll replace
cutout closure with transparency. The intersections inside of the
cutout object will still be ignored.

Allows to have effects like

That new effect is really cool :) I can definitely see some good usage for it in engineering and architecture. And it then makes sense to have it as a node.

Just experimenting with proper fit of the node into the shader tree

Allows to have effects like

I think it is really cool but there are some things to be thought out

  • Having it in a shading node also has advantages, but the interactions are still weird in some cases . Not sure about semantics of a mix node at 50% and this rather binary effect ..
  • It might still be better to have this as a per object flag.
    • Visible to camera + cutout this would give normal cutout.
    • Visible to shadow visible + cutout .. would be some kind of weird portal like effect
    • Not sure about the other combinations though

We can already obtain this kind of effect by multiplying a texture by camera ray.

So, if the interest is to h,ave an easy set-up with objects in viewport, it is probably more valuable to have it as an object option.

@ronan ducluzeau (zeauro), it's fine for as long as you cut out simple shapes. Imagine setup when you need to do several box-shaped cutouts. And then on top of that imagine you want a turntable of the object with cutout (with cutout following the object). Would be really tricky to do it with camera ray.

@Martijn Berger (juicyfruit), yeah, not sure it's really a shader closure. Was mainly experimenting to see how much forward we can push this idea. Just was feeling Cycles should mainly be controlled by shaders.. Not strongly connected to this idea tho and will be fine moving it to an object option (wouldn't mind refactoring some code first to free up more bits for object flags).

@Brecht Van Lommel (brecht), think it's time to summon you to the discussion. The patch is testable, so let's start review starting from the semantics/user interaction ;)

Currently what i have in the TODO:

  • Make it work for split kernel (or consider it unsupported initially, bring it back eventually, but with nice UI feedback about this).
  • There seems to be some infinite loop happening in certain cases, needs investigation.
  • Fix missing Volume stack update.
  • Make it more unified API to keep track of stacks (maybe as separate commit?)
  • Update comments.

@ronan ducluzeau (zeauro), it's fine for as long as you cut out simple shapes. Imagine setup when you need to do several box-shaped cutouts. And then on top of that imagine you want a turntable of the object with cutout (with cutout following the object). Would be really tricky to do it with camera ray.

Camera Ray does not mean Camera Mapping.

You can do complex shapes following the object with a simple UVTexture.

I don't see the benefit as a closure on another object if filling between 2 walls of solidify needs another object anyways.

@ronan ducluzeau (zeauro), now, animate that cutout. Or keep cutout in sync across multiple objects. Surely doable, but is rather tedious.

Additionally, having a separate object to control this could find a real use on complex shots optimizations, so you can cutout certain areas for certain rays without need to go to a library file and tweak object shader specifically for that case.

@ronan ducluzeau (zeauro), now, animate that cutout. Or keep cutout in sync across multiple objects. Surely doable, but is rather tedious.

It is tedious now because of a lack of 3DView Widgets for texture mapping.
For 2.8, it would be great to have a kind of texture space display to help to transform/animate mapping of selected texture node.

I think doing this using objects is the right solution, even if textures let you do some similar things. The purpose here is to be able to apply the cutout on an entire scene without having to go and modify the materials for each object in the scene.

To me this makes most scenes as an object option, we don't currently have any closures that don't use their mixing weight and I'm not sure that's something we should start doing? I think there is a reasonable interpretation for the closure weight, which would be to make the objects partially transparent rather than completely invisible, but that seems more complicated than what we really need here.

@Brecht Van Lommel (brecht), there are indeed various interpretations of how weight can be treated here. I'll be fine going a simple route and use object flag instead. But also wouldn't min hearing back from @Martijn Berger (juicyfruit) whether he have some strong opinion here.

Made it an object option

Still TODO: Support cutout for indirect rays in BPT.

Support indirect rays for branched path tracing

Think now patch is ready for final review and test.

Sergey Sharybin (sergey) retitled this revision from Cycles: Experiment with cutout closure to Cycles: Experiment with cutout object.Apr 28 2017, 10:01 AM
Sergey Sharybin (sergey) edited the summary of this revision. (Show Details)

Is this plan for more involved raytrace csg? - or just single feature?

@Campbell Barton (campbellbarton), don't have plans for anything more involved here. But it;s not really CSG -- the whole idea of this change is to allow cutting objects without causing light to "leak" to a "hole". So ti's like ray visibility/modification tool.