Cutting geometry by a primitive (feature?)

[ruthenoid]

Could boolean operations be someday possible in octane?
I mean cutting through a building or an engine by a cube (with some special invisible shader attached to it), to show the inner parts.

I understand that cutting geometry (boolean difference) is not trivial and could be a nightmare for the devs.
However, may be, there is a way to implement it, without dealing with remeshing. May be octane could just ignore any samples from within the cube, and the only trouble would be the surfaces created by the cut (here I have no clue at all). May be it would be easier, if cutting by arbitrary geometry is not implemented at all, and instead there are just two internal octane objects like a cube and a plane and that's it (cutting a cow with a horsey would certainly be an overkill).

This would be an awsome feature, so i'm curious about the feasability.
Thank you!

[Phantom107]

Shouldn't this be up to the modeling app?

[itsallgoode9]

Shouldn't this be up to the modeling app?

Not necessarily. Maxwell Render allows some primitive booleans at render time. Among other uses, it allows you to do some easy cross section renders and animations that would be a nightmare if you were try to actually boolean the model. In cases of Maya, booleans on anything but the most basic models just plain doesn't work.

[Goldorak]

I looped back internally with the team on this feature some time back, as I also was thinking this could be useful. While it could be exposed, in theory, as a custom type of clipping tool in the V3 renderer, it turned out not to be a trivial amount of work. This is why it has not been placed on the roadmap ahead of current critical 3.x features that don't have fallbacks like this one does (via a host DCC modeler as pointed out above - even if that's inelegant) . That being said, we may review again once the 3.x to-do list gets thinner.

[mesut]

very very much looking forward to a boole at rendertime feature.
working around this with shader-compositings is taking quite the ressources.
would be great to use vray 3.4 clipping functionality as the goal to reach.
way more powerful and flexible than maxwell's boolean operater.

I looped back internally with the team on this feature some time back, as I also was thinking this could be useful. While it could be exposed, in theory, as a custom type of clipping tool in the V3 renderer, it turned out not to be a trivial amount of work. This is why it has not been placed on the roadmap ahead of current critical 3.x features that don't have fallbacks like this one does (via a host DCC modeler as pointed out above - even if that's inelegant) . That being said, we may review again once the 3.x to-do list gets thinner.

[FrankPooleFloating]

Last February I posted in another thread - and it still applies: Oh man, that clipper stuff is exactly the kind of boolean operation shite I was talking about when we were in closed v2 beta! And not just for cutaways etc... If we could use instances to subtract from geo, and the geo being cut/clipped received the surfaces of the instances, we would be able to make a hell of a lot more than swiss cheese... the possibilities are sick.

[Goldorak]

Last February I posted in another thread - and it still applies: Oh man, that clipper stuff is exactly the kind of boolean operation shite I was talking about when we were in closed v2 beta! And not just for cutaways etc... If we could use instances to subtract from geo, and the geo being cut/clipped received the surfaces of the instances, we would be able to make a hell of a lot more than swiss cheese... the possibilities are sick.

It definitely would be cool, and we want to consider how to do it right and not take a speed hit. The reason I asked the dev team earlier about putting this on the roadmap, was because I thought (as a user, not a dev) there was enough flexibility in the camera system in V3 to make something like this possible. For example, power users have hacked the reverse baking feature to work as a mesh based custom camera lens (potentially with clipped displacement map that could be fed in from a previous render pass). The thinking was that internally we could take this further for arbitrary clipping values. The feedback was that doing this incorrectly might slow things down, and doing it ahead of already announced features, might push those out, which we don't want to do.

So it is on our radar, and we will revisit how it might be done once we have the larger stuff on the roadmap cleared up - glTG bone/skinning, headless rendering, AS, new imager, rounded edges, 3rd party modules are next (ORC is also out of invite mode this month). We are also considering a closed test release with OSL to get early feedback on bugs ahead of 3.1 alpha drop for all to bang on. We had also been planning to that wth the 3.0 AMD build, but again, AMD can't get their drivers in a place where this would be of any value for a real release.