I'm trying to do some 3D boolean operations with CGAL. I have successfully converted my polyhedra to nef polyhedra. However, when ever I try doing a simple union, I get an assertion fail on line 286 of SM_overlayer.h:
CGAL error: assertion violation!
Expression : G.mark(v1,0)==G.mark(v2,0)&& G.mark(v1,1)==G.mark(v2,1)
File : ./CGAL/include/CGAL/Nef_S2/SM_overlayer.h
Line : 287
I tried searching the documentation for "mark". Apparently it is a template argument on the Nef_polyhedron_3" that defaults to bool. However the documentation also says it is not implemented and that you shouldn't mess with it. I am a bit confused why there is even an assertion on some unimplemented feature. I tried simply commenting out the assertion, but it simply goes on to fail at a later point.
I am using the following kernel and typedefs as it was the only example I could find that allowed doubles in the construction of the meshes.
typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
typedef CGAL::Nef_polyhedron_3<Kernel> Nef_polyhedron;
typedef CGAL::Polyhedron_3<Kernel> Polyhedron;
I used CGAL 4.6.3 installed with the exe installer. I have also tried the 4.7 beta and I get the same exception(at line 300 instead though).
Related github issue: https://github.com/CGAL/cgal/issues/353
EDIT: The issue turned out to be with the meshes. The meshes I were using had self intersections. Thus, even though is_valid, is_closed and is_triangular returned true, the mesh was in valid for conversion to a nef polyhedron. From CGAL 4.7. The Polygon mesh processing package has been introduced which contains this which can be used to check for self intersections.
Related
I am trying to install the software Sibaco, but I get an error relative to CGAL class Alpha_shape_cell_base_3.
/usr/local/include/CGAL/Regular_triangulation_3.h:1230:12: error: ‘class CGAL::Alpha_shape_cell_base_3<CGAL::Epick, CGAL::Triangulation_cell_base_3<CGAL::Epick, CGAL::Triangulation_ds_cell_base_3<CGAL::Triangulation_data_structure_3<CGAL::Alpha_shape_vertex_base_3<CGAL::Epick, CGAL::Regular_triangulation_vertex_base_3<CGAL::Epick> >, CGAL::Alpha_shape_cell_base_3<CGAL::Epick> > > >, CGAL::Boolean_tag<false>, CGAL::Boolean_tag<false> >’ has no member named ‘hide_point’
A similar error is reported for the members ‘hidden_points_begin’ and ‘hidden_points_end’.
I am using CGAL-4.11.3, since for later releases of CGAL I get many more errors when I try to install the software.
Any help to address this problem would be really appreciated!
The cell base needs to match the triangulation. Since you're using a regular triangulation, the cell base must be a model of the concept RegularTriangulationCellBase_3, so CGAL::Regular_triangulation_cell_base_3 for example.
As pointed in the comment above, the example ex_weighted_alpha_shapes_3.cpp shows a correct setting of vertex and cell for 3D weighted alpha shapes.
If you need to use some more recent CGAL features and CGAL 4.11 is too old, feel free to post the errors you get and we can maybe help you upgrade the code from that library.
So I tried using code from another post around here to see if I could use it, it was a code meant to utilize a potentiometer to move a servo motor, but when I attempted to compile it is gave the error above saying No operator "=" matches these operands in "Servo_Project.cpp". How do I go about fixing this error?
Just in case ill say this, the boards I was trying to compile the code were a NUCLEO-L476RG, the board from the post I mentioned utilized Nucleo L496ZG board and a Tower Pro Micro Servo 9G.
#include "mbed.h"
#include "Servo.h"
Servo myservo(D6);
AnalogOut MyPot(A0);
int main() {
float PotReading;
PotReading = MyPot.read();
while(1) {
for(int i=0; i<100; i++) {
myservo = (i/100);
wait(0.01);
}
}
}
This line:
myservo = (i/100);
Is wrong in a couple of ways. First, i/100 will always be zero - integer division truncates in C++. Second, there's not an = operator that allows an integer value to be assigned to a Servo object. YOu need to invoke some kind of Servo method instead, likely write().
myservo.write(SOMETHING);
The SOMETHING should be the position or speed of the servo you're trying to get working. See the Servo class reference for an explanation. Your code tries to use fractions from 0-1 and thatvisn't going to work - the Servo wants a position/speed between 0 and 180.
You should look in the Servo.h header to see what member functions and operators are implemented.
Assuming what you are using is this, it does have:
Servo& operator= (float percent);
Although note that the parameter is float and you are passing an int (the parameter is also in the range 0.0 to 1.0 - so not "percent" as its name suggests - so be wary, both the documentation and the naming are poor). You should have:
myservo = i/100.0f;
However, even though i / 100 would produce zero for all i in the loop, that does not explain the error, since an implicit cast should be possible - even if clearly undesirable. You should look in the actual header you are using to see if the operator= is declared - possibly you have the wrong file or a different version or just an entirely different implementation that happens to use teh same name.
I also notice that if you look in the header, there is no documentation mark-up for this function and the Servo& operator= (Servo& rhs); member is not documented at all - hence the confusing automatically generated "Shorthand for the write and read functions." on the Servo doc page when the function shown is only one of those things. It is possible it has been removed from your version.
Given that the documentation is incomplete and that the operator= looks like an after thought, the simplest solution is to use the read() / write() members directly in any case. Or implement your own Servo class - it appears to be only a thin wrapper/facade of the PwmOut class in any case. Since that is actually part of mbed rather than user contributed code of unknown quality, you may be on firmer ground.
My question is similar to this one but part of the (useful) given answer isn't compatible with compiling GLSL for vulkan based on OpenGL ES ESSL 3.10.
In order to use a separate section of the push constant memory in the vertex shader and the fragment shader, the suggested solution is to use layout(offset = #) before the first member of the push constant structure.
Attempting to do this in GLSL ES 310 code leads to the error "'offset on block member': not supported with this profile: es".
Is there a supported way to declare such an offset that is compatible with es?
The only workaround I've found is to declare a bunch of dummy variables in the fragment shader. When I do so, I get validation layer errors if I don't declare the full range of the fragment shader's push constant buffer in VkPipelineLayoutCreateInfo. After fixing that, I get validation layer warnings about "vkCreatePipelineLayout() call has push constants with overlapping ranges".
Obviously I can ignore warnings, but if there's a tidier solution, then that would be much more preferable.
Simple example, this compiles successfully with VulkanSDK\1.0.13.0\Bin\glslangValidator.exe:
#version 430
#extension GL_ARB_enhanced_layouts: enable
layout(std140, push_constant) uniform PushConstants
{
layout(offset=64) mat4 matWorldViewProj;
} ubuf;
layout(location = 0) in vec4 i_Position;
void main() {
gl_Position = ubuf.matWorldViewProj * i_Position;
}
Whereas this does not:
#version 310 es
#extension GL_ARB_enhanced_layouts: enable
layout(std140, push_constant) uniform PushConstants
{
layout(offset=64) mat4 matWorldViewProj;
} ubuf;
layout(location = 0) in vec4 i_Position;
void main() {
gl_Position = ubuf.matWorldViewProj * i_Position;
}
Converting all my 310 ES shader code to 430 would solve my problem, but that wouldn't be ideal. GL_ARB_enhanced_layouts doesn't apply to 310 ES code, so my question is not about why it doesn't work, but rather, do I have any options in ES to achieve the same goal?
I would consider this an error in the GLSL compiler.
What's happening is this. There are some things which compiling GLSL for Vulkan adds to the language, as defined by KHR_vulkan_glsl. The push_constant layout, for example, is explicitly added to GLSL syntax.
However, there are certain things which it does not add to the language. Important to your use case is the ability to apply offsets to members of uniform blocks. Oh yes, KHR_vulkan_glsl uses that information when building the shader's block layout. But the grammar that allows you to say layout(offset=#) is defined by GLSL, not by KHR_vulkan_glsl.
And that grammar is not a part of any version of GLSL-ES. Nor is it provided by any ES extension I am aware of. So you can't use it.
I would say that the reference compiler should, when compiling a shader for Vulkan, either fail to compile any GLSL-ES-based version, or silently ignore any version and extension declarations, and just assume desktop GLSL 4.50.
As for what you can do about it... nothing. Short of hacking that solution into the compiler yourself, your primary solution is to write your code against versions of desktop OpenGL. Like 4.50.
If you compile SPIR-V for Vulkan there is a "VULKAN" define set in your shaders (see GL_KHR_VULKAN_glsl), so you could do something like this:
#ifdef VULKAN
layout(push_constant) uniform pushConstants {
vec4 (offset = 12) pos;
} pushConstBlock;
#else
// GLES stuff
#endif
I'm trying to do the aggregate insertion of x-monotone polylines, but I get the following error:
terminate called after throwing an instance of 'CGAL::Precondition_exception'
what(): CGAL ERROR: precondition violation!
Expr: i != INVALID_INDEX
File: /home/vladimir/lib-cgal/include/CGAL/Arr_polycurve_basic_traits_2.h
Line: 727
And have no clue why it happens. Do I miss something? Is my input wrong? Or is it a bug? Here is a code snippet resulting in this behavior:
#include <vector>
#include <CGAL/Exact_predicates_exact_constructions_kernel.h>
#include <CGAL/Arr_segment_traits_2.h>
#include <CGAL/Arr_polyline_traits_2.h>
#include <CGAL/Arrangement_2.h>
typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
typedef Kernel::Point_2 Point_2;
typedef CGAL::Arr_segment_traits_2<Kernel> Segment_traits_2;
typedef CGAL::Arr_polyline_traits_2<Segment_traits_2> Geom_traits_2;
typedef CGAL::Arrangement_2<Geom_traits_2> Arrangement_2;
int main()
{
Arrangement_2 arr;
std::vector<Geom_traits_2::X_monotone_curve_2> segments;
{
auto ctor = arr.geometry_traits()->construct_x_monotone_curve_2_object();
typedef std::vector<Point_2> Line;
std::vector<Line> lines = {
{{0,0}, {8,0}},
{{2,0}, {7,0}},
{{4,2}, {6,3}},
{{1,1}, {3,0}, {5,0}},
};
for (auto &line: lines) {
segments.push_back(ctor(line.begin(), line.end()));
}
}
insert(arr, segments.begin(), segments.end());
return 0;
}
CGAL version I'm using is 4.7, but I have tried it with 4.5.2 and the lates git version (81d638341) with the same result.
The lines are intersecting, but that should be fine as I understand. I have observed that changing {{1,1}, {3,0}, {5,0}} to {{2,1}, {3,0}, {5,0}} results in no error. And splitting {{1,1}, {3,0}, {5,0}} into two segments {{1,1}, {3,0}}, {{3,0}, {5,0}} results in no error as well.
I have also noticed another thread (link) with similar problem which was fixed, but I don't see this fix in the version 4.7. Probably it's fixed somewhere else in the code, or perhaps this fix got lost somehow.? Anyway, it looks like it's not related to my problem, but one never knows.
I was able to reproduce the problem and at first glance it looks like a bug. We are looking into it, but for now you have 2 options to work around the problem:
1. Use incremental insertion. The incremental insertion is based on a completely different algorithm.
2. Break each polyline into segments and construct an arrangement of segments instead of an arrangement of polylines. I've tested it with the minimal example that produces the problem you provided (that you, by the way for that) and it works fine.
BW, the link you mentioned is unrelated.
I an using Nef Polyhedra for some 3D boolean operation. I first convert a bunch polyhedron_3 meshes into Nef_polyhedron_3 meshes and then perform the boolean operation. However, almost any manipulation of the Nef polyhedra results in a bunch of Uncertain_conversion_exception. I tried running CGAL with CGAL_PROFILE profile. This told me that the I get this exception on two different types. These are
GCAL::Uncertain<enum CGAL::Sign>
CGAL::Uncertain<bool>
Especially the second is thrown a lot. They are throw both when converting meshes into Nef polyhedra and during the boolean operations them selves. The call that that throws the exception is made in Filtered_predicate. The exceptions are being handled here and the boolean operation returns the expected result. However, the exceptions seems to slow down the operations quite a bit.
I am experiencing this with CGAL 4.7 on windows using visual studio 2015.I have the following symbols defined for the preprocessor
WIN32;
_WINDOWS;
_CRT_SECURE_NO_DEPRECATE;
_SCL_SECURE_NO_DEPRECATE;
_CRT_SECURE_NO_WARNINGS;
_SCL_SECURE_NO_WARNINGS;
_DEBUG;CGAL_USE_MPFR;
CGAL_USE_GMP;
BOOST_ALL_DYN_LINK;
CMAKE_INTDIR="Debug";
CGAL_EXPORTS;
CGAL is built with the flags: /GR, /EHsc, fp:strict, fp:except-, /wd4503 and /bigobj.
Additionally the project that includes CGAL is build with the flags: /GS /Zc:wchar_t /Zc:inline /fp:precise /Zc:forScope /clr /MDd /EHa
I left out a bunch flags that didn't seem relevant like include flags.
Is this expected behavior or can i do something to avoid it?