I am using make_mesh_3 to mesh implicit functions. However, for some models it fails to generate a mesh at all.
For one of the circumstances it fails I assume it is because the mesh generator does not construct a good enough initial set of points. For this instance I am hoping that increasing the number of rays shoot in random directions or changing the point from which they are shot (by default the center of the bounding box) may help alleviate the problem. Is there a way without changing the source code of CGAL to specify the number of rays to shoot and the point from which they are shot?
The other circumstance under which it seems to fail regularly is when the volume becomes very thin. Is there any way to keep this from happening?
Related
I am currently learning how to sculpt in Blender; working on my own projects after completing BlenderGuru's Beginner & Intermediate classes, and some of Grant Abbitts videos with pleasing results. I am trying to sculpt a plasmapistol with a skull on it, which can be seen in the reference photo that I have provided.
However, when I sculpt, I get these really odd linear artefacts (See picture below, circled in black). I added a Subsurf Modifier to the primitive UV Sphere, with the Viewport and Render Values set to 4, so it is a fairly fine mesh. However, these still artefacts occur.
I assume it is due to the stretching of the polygons when I grab the sphere with the Snake Hook tool and deform it to encompass the frontal part of the skull.
EDIT: Whilst writing this comment I went back, and switched on Dynamic Topology with Relative Detail selected.
It appears that I am no longer getting the issues that I was getting last night with the linear artefacts.
Can I confirm that these problems are a result of having the incorrect Dynamic Topology settings for using the Snake Hook Tool; I was using Constant Detail instead of Relative Detail, or is this being caused by another issue?
Also, any advice on avoiding common pitfalls when choosing the settings in sculpting would be most appreciated.
I will continue to ask this question incase anyone has a similar problem and it can be resolved by reading this.
Sculpt, showing lineations
Experimenting with Dynamic Topology
In Object Mode, does the object have uniform X, Y, & Z scaling? If not, you can apply the scale from the object menu.
Object ‣ Apply ‣ Scale / Rotation & Scale
I am attempting to mesh a complicated design (~80,000 faces) for a microchannel heat sink, as pictured, and I would appreciate some advice. I have tried a range of different mesh controls (especially face sizing and body sizing), mesh settings and element sizes, and all have failed to produce a working mesh. The most common errors are shown in the linked picture, in particular the one regarding "The following surfaces cannot be meshed with acceptable quality. Try using a different element size or virtual topology." However, I have already reduced the element size to 2x10^-6 m, which takes two days to resolve before failure.
Unfortunately I cannot alter the geometry significantly, as it is imported from generation in SolidWORKS as either a STEP or an x.t file. As such, any advice for how I can successfully mesh the geometry for CFD analysis in FLUENT would be greatly appreciated.
I can provide more details or the geometry file itself if required.
Thanks in advance.
Meshing Attempt
Probably your cad design is not clean at all. But it is impossible to notice from this image. If you don't have control over the geometry source it is trouble. Because you might ask somebody else about check and fix something. First check you can do with your model it's trying to reduce the number of elements until the minimum possible value. Then if the mesh runs properly you can relay in the surfaces of your cad model. After that, you can refine the mesh, but the refining process is something that you have to do following some error criteria. If you are also the designer why not try to simplify a bit the geometry if you consider it is really hard to mesh? Meshing properly is a hard task, you should go step-by-step until you reach some solution. Also, you must not allow the preprocessor mesh automatically, without giving some criteria. Probably the first thing you have to answer even before apply any mesh is, what is your Reynolds number? And what is the most valuable result in which you can base the goodness of your discretization?
Thank you for your suggestions. In the end I solved the issue by importing the original mesh generated by COMSOL into SpaceClaim, then employing both the "Smooth" and "Reduce Faces" tools in tandem to simplify the geometry, before finally using SolidWORKS to turn the smoothed mesh into a solid body. This body retained many of the same features as the original, but was much less complex, having two orders of magnitude fewer faces. In turn, this permitted both meshing and heat transfer analysis in FLUENT.
I'm new to CGAL and I'm trying to cut a cube with an arbitrary surface mesh in 3d (no self intersections, not closed/no volume). The goal is to get a volume which consists of one "side" of the cut cube, closed by the part of the surface inside the cube.
The surface itself consists of unordered triangles which should have the same winding order (consistent normal directions) but have no neighborhood information and could contain same points multiple times for different triangles.
I tried to use the clip function, like:
CGAL::Polygon_mesh_processing::clip(cube,surface,true);
Which of course does not work because the surface is not closed (as far as I understood). But It shows the idea on how the operation should work.
Boolean operations (https://doc.cgal.org/latest/Polygon_mesh_processing/index.html#title14)) cannot be used for this as well since they are calculated on volumes and the surface has no volume.
I also thought about extending the outside of the surface so that it is closed. This, however, does not seem like a good approach.
Sadly, my research on similar problems was not successful.
I'm pretty sure that there is a nice way to do this in CGAL. Maybe someone with more experience in CGAL knows how to do this.
What would be the best approach for getting this volume?
Regards
EDIT:
By removing redundant points in my surface mesh I was able to get clip to work. Nevertheless, I do not always get the right side of the volume, even though the winding order should yield normals which point to the outside.
Is it necessary to calculate the normals and pass them as an extra parameter (see here) of the surface before the cut in order to always get the same "inner" side of the volume?
Also, the clip function seems to be quite slow. I have to do this cut for a very high number of cubes and different surfaces.
I use CGAL as header only lib and without GMP and MPFR, since it crashed my other application. How big is the speedup using these libraries and are there any other tricks which can be used to speedup computation, e.g. using parallelization?
I saw that CGAL uses Intel's TBB which. But in the header files which are included by the clipping algorithm CGAL_LINKED_WITH_TBB is not tested.
Thanks
It was a problem with the clipping mesh. Clipping could not be done properly. I increased it size and now it always intersects the volume.
Im trying to transform a path along an arc.
My project is running on osX 10.8.2 and the painting is done via CoreAnimation in CALayers.
There is a waveform in my project which will be painted by a path. There are about 200 sample points which are mirrored to the bottom side. These are painted 60 times per second and updated to a song postion.
Please ignore the white line, it is just a rotation indicator.
What i am trying to achieve is drawing a waveform along an arc. "Up" should point to the middle. It does not need to go all the way around. The waveform should be painted along the green circle. Please take a look at the sketch provided below.
Im not sure how to achieve this in a performant manner. There are many points per second that need coordinate correction.
I tried coming up with some ideas of my own:
1) There is the possibility to add linear transformations to paths, which, i think, will not help me here. The only thing i can think of is adding a point, rotating the path with a transformation, adding another point, rotating and so on. But this would be very slow i think
2) Drawing the path into an image and bending it would surely lead to image-artifacts.
3) Maybe the best idea would be to precompute sample points on an arc, then save save a vector to the center. Taking the y-coordinates of the waveform, placing them on the sample points and moving them along the vector to the center.
But maybe i am just not seeing some kind of easy solution to this problem. Help is really appreciated and fresh ideas very welcome. Thank you in advance!
IMHO, the most efficient way to go (in terms of CPU usage) would be to use some form of pre-computed approach that would take into account the resolution of the display.
Cleverly precomputed values
I would go for the mathematical transformation (from linear to polar) and combine two facts:
There is no need to perform expansive mathematical computation
There is no need to render two points that are too close from each other
I have no ready-made algorithm for you, but you could use a pre-computed sin or cos table, and match the data range to the display size in order to work with integers.
For instance imagine we have some data ranging from 0 to 1E6 and we need to display the sin value of each point in a 100 pix height rectangle. We can use a pre-computed sin table and work with integers. This way displaying the sin value of a point would be much quicker. This concept can be refined to get a nicer result.
Also, there are some ways to retain only significant points of a curve so that the displayed curve actually looks like the original (see the Ramer–Douglas–Peucker algorithm on wikipedia). But I found it to be inefficient for quickly displaying ever-changing data.
Using multicore rendering
You could compute different areas of the curve using multiple cores (can be tricky)
Or you could use pre-computing using several cores, and one core to do finish the job.
I am writing a physics simulation using Ogre and MOC.
I have a sphere that I shoot from the camera's position and it travels in the direction the camera is facing by using the camera's forward vector.
I would like to know how I can detect the point of collision between my sphere and another mesh.
How would I be able to check for a collision point between the two meshes using MOC or OGRE?
Update: Should have mentioned this earlier. I am unable to use a 3rd party physics library as we I need to develop this myself (uni project).
The accepted solution here flat out doesn't work. It will only even sort of work if the mesh density is generally high enough that no two points on the mesh are farther apart than the diameter of your collision sphere. Imagine a tiny sphere launched at short range on a random vector at a huuuge cube mesh. The cube mesh only has 8 verts. What are the odds that the cube is actually going to hit one of those 8 verts?
This really needs to be done with per-polygon collision. You need to be able to check intersection of polygon and a sphere (and additionally a cylinder if you want to avoid tunneling like reinier mentioned). There are quite a few resources for this online and in book form, but http://www.realtimerendering.com/intersections.html might be a useful starting point.
The comments about optimization are good. Early out opportunities (perhaps a quick check against a bounding sphere or an axis aligned bounding volume for the mesh) are essential. Even once you've determined that you're inside a bounding volume, it would probably be a good idea to be able to weed out unlikely polygons (too far away, facing the wrong direction, etc.) from the list of potential candidates.
I think the best would be to use a specialized physics library.
That said. If I think about this problem, I would suspect that it's not that hard:
The sphere has a midpoint and a radius. For every point in the mesh do the following:
check if the point lies inside the sphere.
if it does check if it is closer to the center than the previously found point(if any)
if it does... store this point as the collision point
Of course, this routine will be fairly slow.
A few things to speed it up:
for a first trivial reject, first see if the bounding sphere of the mesh collides
don't calc the squareroots when checking distances... use the squared lengths instead.(much faster)
Instead of comparing every point of the mesh, use a dimensional space division algorithm (quadtree / BSP)for the mesh to quickly rule out groups of points
Ah... and this routine only works if the sphere doesn't travel too fast (relative to the mesh). If it would travel very fast, and you sample it X times per second, chances are the sphere would have flown right through the mesh without every colliding. To overcome this, you must use 'swept volumes' which basically makes your sphere into a tube. Making the math exponentially complicated.