Thanks Steve. ValueAt will return 0 for vertices /on/ the plane, so it seems like an unreliable way to determine which side the mesh is on. I went instead for the Center of the BoundingBox of each mesh.
However I have now found that Split is returning meshes with no normals. Is that a bug? There is no mention in the RhinoCommon doco on this. Do I need to call Mesh.Normals.ComputeNormals() after Split()?
Also - if there are say 5 clipping plane, the management of the many many meshes arising from this process is a little ugly.
Ok. I just want to point out possibly the obvious… I skimmed the whole thread in hopes of not being off topic.
From a User’s point of the view the Octane Rhino Plugin is great, but clunky to use in many ways, primarily with Entering Numbers, which is used to control so much of the interface. Incrementing numbers is a ‘type and return’ ordeal, not an arrow key / Shift + Arrow. This sucks when the scale of the number may vary 1-1024 but only a 7-10 range is desired. Case in point, below.
A Near Clip Plane IS implemented in Octane for Rhino, in the same way they work in Standalone Octane but these are independent of the Rhino Clip planes. They ARE however, tied to the Viewport , and it’s Near Clip distance it is very touchy and a PITA to use.
Like I said, the Rhino Clip planes ARE ignored by Rhino Octane Plugin. Yes, I know, this would be ideal, yes, programmers could Dream all day about how… but the When is NOW.
I am proposing a “Workaround” that sucks, but can get you the cut-away you need. Kind-of.
Did I mention is sucks and is touchy? Ok. { End Disclaimer }
Go ahead and Save your view in Rhino as normal. [Named Views Panel]
You must be able to get back to the exact angle and distance from
Subject.
You may want to orient your camera roughly parallel to an
exterior/interior wall (Interior Arch example), as the Clip Plane
levied by the Octane camera is ALWAYS normal to your view. So, Triangular
clips out of walls may look weird, but whole walls missing is more mentally believable, like our peripheral vision.
Here’s the Trick. Increment the Camera > Near Clip Plane Float Value. Try to use the slider to find the distance range where Octane begins to clip your subject. Then, move it up in steps of 1 (one). Find the EXACT whole number where the Clip plane is Close to the depth you need. You should now be looking INSIDE the mesh / room / subject.
To fine tune the clip a tiny bit more, use Ctrl + RMB (or your settings) to slighty dolly the camera in or out in the Rhino Viewport.
Here are some examples I achieved, note that I will need to crop away the fake looking environment, but with a higher quality .hdr, a realistic view from out the doorway should be possible.
No Clip, Set to Zero :
Clip set to between 8-10.
Note the Clipped Wall difference between the Rhino and Octane Viewport. Success? Kindof.
Open EXR, Sampled down to 8bit in Photoshop.
Good Luck Octane fueled Rhino artists !
Sef. Sefpinney.com
@stevebaer Any news on the issues I listed above? In particular…
ValueAt will return 0 for vertices /on/ the plane, so it seems like
an unreliable way to determine which side the mesh is on. I went
instead for the Center of the BoundingBox of each mesh.
However I have now found that Split is returning meshes with no
normals. Is that a bug? There is no mention in the RhinoCommon doco on
this. Do I need to call Mesh.Normals.ComputeNormals() after Split()?
Also - if there are say 5 clipping plane, the management of the many many meshes arising from this process is a little ugly.
Another issue…if you have a vertical Surface Plane, and a horizontal clipping plane, Split() returns 0 meshes.
This sounds like several bugs that we should fix. @andy are there any plans for assisting renderers when clipping planes are present in V6. Seems like something we should try to improve on (even if it just means fixing the bugs that Paul points out)
There are no current plans - it can be very diffiicult to implement clipping planes without in-renderer support as we’ve discussed previously. Unfortunately, the mesh splitting tools are due for an improvement, and these problems are almost certainly bugs in the tools.
It would be really terrific if support for clipping planes could be implemented for the Octane Render plugin for Rhino. More specifically, being able to animate the clipping planes with Bongo and having them render correctly via Octane really opens up a lot of doors (animation wise) with using Bongo and Octane.