When having a level with toggle cut plane=true and in addition to that using a vertical Rhino clipping plane, I get the following bug. Please see the video for it. Thanks for looking into it.
Wow, this is the first time I see this bug. I’ve been able to reproduce it:
I’ll try to fix it for the next VisualARQ update.
Thanks for reporting it!
I’m fixed this bug in VisualARQ 2.11.3. We’ll publish it next week.
Hi @silvano ,
VisualARQ 2.11.3 has been released and this issue has been fixed. You can see more details about it in the following post:
I don’t want to be this guy… but at least for me, it’s not working how it should.
Very strange behavior of selecting Clipping Plane when the section is turned on. Can’t window select it (right to left), can’t click and select, but window select (left to right) if working. Also, there is a slice of geometry still showing in the viewport.
clipping plane section.3dm (56.9 KB)
Don’t worry. You must “be that guy” if we haven’t fixed the issue.
I’m checking it right now. I hope I can fix this today, and I’ll PM you a link to download a build with the fix.
I’ve fixed the display bug. The problem is that I fixed the issue only when a clipping plane and a level cut plane are both enabled, and I didn’t test it with the VisualARQ sections. Although both features are similar, they use very different code, because sections support jogs, and jogs require a multiple-pass render to achieve the final image.
I’ve also fixed the selection problems.
As soon as we test the new build I’ll OM you the link.
I really like VA Sections in 3D views.
BTW multiple-pass render, would you like share some thoughts on technical difficulties of making something like “void” clipping object? Something like a section but with limited height, or Section Box working inward or outward. Maybe not crucial in architecture but very attractive in the product design.
Example made with boolean difference just to show what I mean - purple shape as a cutting void
If the void object has any surface that is not planar, this is something very difficult to implement, as OpenGL (the graphics API used by Rhino) can only trim geometry by using clipping planes. Also, if the object is concave, it is required first to split it into convex pieces. Finally, there is also a limit on the number of active clipping planes (usually 8), so if any of the convex pieces have more than 8 surfaces, these pieces will need also to be split further to reduce the number of surfaces. Then, to render the frame, we’ll need to make a pass for each subtracting solid piece.
In the sample image, a single pass is required, because a box has only 6 planes and it is already convex. In fact, implementing this feature in VisualARQ would be pretty simple…
+1 for box clipping, if it’s not too hard. Revit has this, too.
Regarding the clipping with ‘free’ objects: you could use VA’s boolean feature as a workaround - the boolean inputs remain ‘live’ and editable. It will however not create hatches at the section surfaces. How could it - if you used a cylindrical cutter, and hatches can only be planar.
Great tip. I see where it’s coming from
If there would be an option to “hatch” those intersections it could be also interesting. After all, Rhino is a surface modeler, I wouldn’t mind even a hatch in the form of texture in cases like that. Some proper surface mapping scale could do the trick. Or isocurves, or even screen aligned textures (already possible in Rhino).
If this was made in indestructible manner like with VA Substract Solids it would be great - screen space aligned “hatch” texture
How about modifying Rhino’s render meshes? A couple of years ago I saw some attempts to make a new mesher for Rhino, I believe it was “mesh 2”.
Sorry, If I am looking at things superficially, but in case of complex cuts, could Rhino’s render meshes be modified as they are by Edge Softening or Shut Lining? This might need to introduce different render meshes for different views, so there could be a problem.
Basically, complex cuts would be an internal operation based on mesh booleans of render meshes and void cutter. I think in 2021 mesh booleans (of reasonable meshes because created by Rhino, not some million poly models…) can be done pretty quick?
Maybe we should move this discussion to a separate topic?
Mesh booleans? Evil!
However, I wonder if booleans can return the section surfaces. Then some material and texture mapping could be applied to them automatically, to ‘simulate’ what hatches normally do.
VA booleans are based on Rhino’s built in ones, right? So, it’s McNeels turn to provide such a feature.
I have only basic C++ knowledge, but it does not look like the C++ API function returns the section surfaces:
I know how to get the section surfaces between two objects, this is not a problem. The real problem is how to map a hatch to it without asking the user to specify something like a texture-mapping for each section surface.
In VisualARQ we have plans to implement 3D-hatch patterns and bendable patterns, which should solve this problem, and also allow us to hatch projected surfaces.
- 3D-patterns are similar to 3D textures, so texture mapping is not required.
- bendable-hatches are just 2D hatches in which pattern lines follow a curve/surface.