Topographical Meshes

[Anonymous]

I am having a problem subtracting one mesh from another. I am subtracting one (existing) topographical mesh from another (proposed) to evaluate volumes of cut and fill. They are a meshes of at least an acre in size. The meshes have depth. The meshes are fairly idetical except where I have made cuts and fills by moving the mesh's contour splines. The meshes are each on their own layers.

When I use solid element operation I can not get them to subtract. I have used layers settings, wireframe, etc. to no avail. Have tried opening new files and pasting into them with same results. I can create relatively simple meshes or slabs and they subtract just fine. I am feeling that the meshes are sharing too many vertices in common...

My work around has been to just calculate volumes of each and subtract manually with calculator but doesn't help me discern between cut and fill, only net change.

Thanks

version 9
pc pent 4 3000
1300 ram
xp pro

[Anonymous]

g.h.design wrote:
"When I use solid element operation I can not get them to subtract."

I tried something similar on two almost identical meshes of some complexity
(100+ contours) and I could not get one to subtract from the other.
I tried again with two very simple meshes and the subtraction worked.

Have you tried with two very simple meshes or make two small meshes
of only the area where the two larger meshes are different (where there
is a cut or fill)?

This would test whether the failure might be due to complexity.
In the past several people have reported mesh failures due to complexity.
Peter Devlin

[Anonymous]

I can definately get simpler meshes to subtract.

I did not mention that I have had some minimal success in getting the complex meshes to subtract. I have had it work. The cuts are the only thing remaining. The volume calcs work great. But it only works like once out of maybe 15 to 20 tries. I cannot seem to replicate the settings (mesh depth--have had it work when I have made one depth greater than the other-- is one setting that has helped).

The other thing is that if I move the meshes so that they intersect off set from each other they subtract. So I think it has something to do with them sharing so many vertices in common.

The frustrating thing is to have had it work a few times but being unable to replicate the conditions that made it work....

[Anonymous]

I think you are on to something with your observation about
offsetting the meshes.
I seem to remember in a thread on this forum perhaps a year ago someone observed that SEO did not work if the target and the operator had too meany coincident edges or surfaces. Moving one object a very small amount relative to the other seemed to fix the problem. If you moved one of your meshes say 1/16" relative to the other that might work and hopefully the calculation error would be so small as to be acceptable.
Peter Devlin

[Anonymous]

Yes, it must be a problem with sharing too many common points. If I move the mesh .1" it renders correctly. The problem is that the cubic volume is off by 20% on a large terrain model. When I calc manually comparing the two separate volumes get 160 cubic yards. When I calculate using the s.e.o. and the meshes off-set with from each other I get 200 cubic yards.

I tried moving the meshes back together after they render properly but it doesn't work. I guess I will have to cut away all of the mesh that has no cut or fill and that way I will get a more accurate result.

Sort of tedious, wish there were an accurate work around....

[Anonymous]

errr....

tried cutting away mesh but I run into problems when I cut through topo splines and th cacls get unusable. Way to high of an error.

Mmmm...

[Anonymous]

Is your offset lateral or vertical?
Vertical might give a smaller error
or at least one that a correction factor could be calculated for.

I know I'm flopping around here. I really can't think of a direct
way of solving the problem.

GS has known about this problem with SEO and to many common
edges/surfaces and it is disappointing that the problem is still not
fixed in AC 9.
Peter Devlin

[Anonymous]

I tried it Vertical. The error was smaller (15%).
Oh well...

Thank you for your input.

[Anonymous]

I have just spent 2 days trying to get this to work. Very Frusterating! Please fix this GS!

[Anonymous]

I have found that the solid operations can become flaky when there is too much complexity. Particularly when the operand of one operation is the operator in others. This will undoubtedly improve (considering the SEOs were very unreliable in 8.0, usable in 8.1, and pretty good now).

I don't have any rules of thumb yet for how much is too much or what particular conditions may lead to failure. You can probably get it to work by subdividing the site model (easiest along contours, retaining walls, etc.)

Another cause of problems could be extremely acute angles in the resulting solid, particularly cotangent curves.