Contouring problem on Linux
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
Contouring problem on Linux
Hello,
I am trying to run the Dual Contouring software at
http://www.sandboxie.com/misc/isosurf/isosurfaces.html
and finding that the programs demo1, demo2 and demo3 all exit at SDL_SetVideoMode() in demoio.cpp, i.e.: function returns null pointer.
I tried unsuccessfully the email of Dr. Tzur, whose name appears on this webpage. Can anyone suggest a way of contacting Ronen Tzur, or better still, suggest a means of determining what is going wrong?
Cheers,
Michel
I am trying to run the Dual Contouring software at
http://www.sandboxie.com/misc/isosurf/isosurfaces.html
and finding that the programs demo1, demo2 and demo3 all exit at SDL_SetVideoMode() in demoio.cpp, i.e.: function returns null pointer.
I tried unsuccessfully the email of Dr. Tzur, whose name appears on this webpage. Can anyone suggest a way of contacting Ronen Tzur, or better still, suggest a means of determining what is going wrong?
Cheers,
Michel
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
When in doubt, I'd rather assume the invidual has the credentials. I have a doctorate (too), but insist on being called by my first name, which I'm finding goes against the grain here in Germany. In any event, it's useful in allowing me to call surgeons by their first name, which might not be the case otherwise .
In any event, I think that your contouring stuff is useful to me, for building patient-specific anatomical models for surgery simulation. I've been playing with Marching Cubes as an initialization for a discrete (simplex) surface model, whose mesh size I can control very precisely, and where the initial topology of a surface is provided by MC, but I'm open to something that is more faithful to topology and to edges than MC. So, thanks!
In any event, I think that your contouring stuff is useful to me, for building patient-specific anatomical models for surgery simulation. I've been playing with Marching Cubes as an initialization for a discrete (simplex) surface model, whose mesh size I can control very precisely, and where the initial topology of a surface is provided by MC, but I'm open to something that is more faithful to topology and to edges than MC. So, thanks!
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
Oh, it was amusing to me, because I don't have one.I have a doctorate (too)
That sounds interesting. First of all, good luck in your endeavor!building patient-specific anatomical models for surgery simulation
Can't help you there. First of all, I don't know what Gaussian pre-filtering is.Do you find that the Dual method is less dependent on this pre-processing?
And secondly, I gave up (perhaps temporarily) on toying with 3D graphics shortly after I wrote this article, and I only studied Dual Contouring shortly before writing it.
But from what little I've seen, it seems that DC produces more accurate results than MC, when edges are involved, and equivalent results, when no edges or corners are involved.
tzuk
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
One more comment, this one algorithmic.
Your code assumes that it is possible to evaluate implicit functions at sub-voxel precision, such as when you do calcDensity(xt+0.001f, yt,zt), based on an analytical expression for distance in a sphere , and so on, in order to compute fNormal().
However, in applying dual contouring to volumetric data, the best one can do is compute a signed distance at every voxel, based on the Fast Marching method. It is possible to estimate this distance at sub-voxel level, but this would be based on linear interpolation, for example, between voxels, so you might as well set Epsilon= pixel_spacing_x, or ..._y, or ..._z, rather than .001.
Is this not true, or am I missing something? Can the method work then?
Just wondering.
Michel
Your code assumes that it is possible to evaluate implicit functions at sub-voxel precision, such as when you do calcDensity(xt+0.001f, yt,zt), based on an analytical expression for distance in a sphere , and so on, in order to compute fNormal().
However, in applying dual contouring to volumetric data, the best one can do is compute a signed distance at every voxel, based on the Fast Marching method. It is possible to estimate this distance at sub-voxel level, but this would be based on linear interpolation, for example, between voxels, so you might as well set Epsilon= pixel_spacing_x, or ..._y, or ..._z, rather than .001.
Is this not true, or am I missing something? Can the method work then?
Just wondering.
Michel
The normal is really a psuedo normal. After all, a point on its own doesn't have a direction. Each component of the psuedo normal (x,y, and z) is computed by looking at the evaluation of the function for two nearby points. The smaller the distance between these two points, the more accurate the psuedo normal is.
tzuk
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
-
- Posts: 0
- Joined: Wed Dec 31, 1969 7:00 pm
PlanesList vs FacesList
Hi again,
one more question... for now. A mesh seems to include a PlanesList, each member of which contains a FacesList. Can you indicate the distinction to me between the two? In the example on which I am working, I get several PlanesList members with very few Faces (sometimes 2) in them. Is a Plane a contiguous surface, possibly closed, consisting of several faces?
I'm wondering how to tweak the data or method so that I that I get fewer spurious PlanesLists...
Thanks again for your help. Cheers,
Michel
one more question... for now. A mesh seems to include a PlanesList, each member of which contains a FacesList. Can you indicate the distinction to me between the two? In the example on which I am working, I get several PlanesList members with very few Faces (sometimes 2) in them. Is a Plane a contiguous surface, possibly closed, consisting of several faces?
I'm wondering how to tweak the data or method so that I that I get fewer spurious PlanesLists...
Thanks again for your help. Cheers,
Michel
Plane is the theoretical mathematical entity, an infinite plane in 3-space.
Face is a single triangle.
So the relationship is that a mesh contains a list of planes. Each plane contains the faces (triangles) that are aligned on that plain.
Maybe there bugs or floating point errors that cause triangles that should be on the same plane (that is, be on the same list), to appear on separate planes. But that would be bugs, not the intent.
This helps?
Face is a single triangle.
So the relationship is that a mesh contains a list of planes. Each plane contains the faces (triangles) that are aligned on that plain.
Maybe there bugs or floating point errors that cause triangles that should be on the same plane (that is, be on the same list), to appear on separate planes. But that would be bugs, not the intent.
This helps?
tzuk
Who is online
Users browsing this forum: No registered users and 1 guest