Working with soft selection

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/01/2011 at 05:35, xxxxxxxx wrote:

Nah, never mind.

Figured out how to do. GetActiveTool & descriptions.
But in my opinion not a very good solution. Any other suggestions?

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 28/01/2011 at 21:15, xxxxxxxx wrote:

Okay, again. Seems like coffee can't use the soft-selection option.
Since I'm not very into mathematics, I hope you can help me out.

As written above, I just want to manipulate multiple circular clusters of points or polygons and movem them along their normal. The problem is, I don't know where to put my hands on.
I tried to adapt the Sheet-Stretcher example given in the SDK, but I badly failed.

Here's a view of what I want to achieve.

Really hope, someone can point me in the right direction.

cheers,
Robert

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/01/2011 at 00:18, xxxxxxxx wrote:

Did vertex-maps not work ?
You could create a vertex-map for everyselection you want to move, i think they can even be virtual.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/01/2011 at 02:59, xxxxxxxx wrote:

"not into mathematics" is not exactly a good prerequisite for 3D plugin programming

Here's what you'd need to do manually, if the soft selections cannot be triggered by COFFEE (I didn't try...) :

1. Determine the affected points by distance from the selected point. Distance is the length of the difference vector between the two points.

2. Determine the strength of the effect. That is a falloff function over the aforementioned distance, starting at 1 (at the selected point), ending at 0 (at the outer distance). The shape of this function will be the shape of your effect. In the simplest case, it is linear - see the "Falloff" parameter in the soft selection tool setting.

3. Determine the direction of the effect. A point has no normal on its own - the point's normal is the median of the normals of the adjacent polygons.

4. If you want to do it "correctly", you will have to exclude points that are spatially close, but not directly connected to your selected point.

If this is going to be a tool, there are more things to observe, but I won't go into that.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 29/01/2011 at 16:14, xxxxxxxx wrote:

Ha! Well, thank you.

Just needed a bump into the right direction.
Your first statement helped me out. Through the whole expermienting stuff, I just forgot the simple vector-calculations. That's quite easy.
Thought, it would be neccessary to do some mathematical mind tricks.

"not into mathematics" seems to be quite relative then.

Thanks again,
Robert

edit: Really, thanks a lot. Now everything is going on as it should.
Didn't see the wood for the trees.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 01:34, xxxxxxxx wrote:

No mathematical wizardry needed, just vector calculations, but still, when people say "I'm not into mathematics", I almost came to expect over the years that they mean "hey, what does that little cross + do?"

The worst part here seems to me the limitation of the effect to directly connected points (if that is even desired), because you need to access a "neighborhood" that's not efficiently accessible. But if that's too much work, you can always work with limiting the effect to a point selection that you set manually. Anyway.

Robert, eh? The world is small. "Robert" is a pen name though because $%&§§ CGSociety forces you to enter a name for registration. Oooh, I'm nasty anonymous

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 01:53, xxxxxxxx wrote:

Well, getting the neighbors isn't that hard. Actually, it's quite simple. As long as you have geometry that fits some restrictions.

The hardest part for now seems to calculate a normal from the direct neighbors since the order of points is variable... I dont't want to get it from the corresponding poly-normal due to an optimal performance.
Shame on me, if I'm wrong with that(?).

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 06:08, xxxxxxxx wrote:

Hmm, but poly-normals are calculated from the polygon's points as well?

Basically, a point has no normal. It cannot, because a single point does not define a three-dimensional base system. The idea "a point's normal is the median of the polygon's normals where the point is a part of" is an artificial definition that has certain advantages.

A polygon's normal is the vector that is orthogonal to the plane of the polygon. The plane of a polygon is defined by two of its sides forming a two-dimensional (not necessarily orthogonal) base system. (Note that a polygon in C4D is not necessarily plane; for mathematical calculations on 4-or-more-point polygons you need to assume that the points of the polygon are coplanar, and that the edges defining the plane are not collinear/parallel.)

The normal for a polygon is then calculated by the (normalized) cross product of the two edges (vectors) that define the polygon plane. Note that the sequence of points is relevant to get the normal pointing into the right direction.

So, if you have a polygon P made from points ABC, then Norm(AB x AC) will be your normal (or is it AB x BC? too lazy now to look it up...) Therefore, your normal IS calculated from the points.

Can you calculate the normal from the direct neighbors without looking at the polygons? No! The polygons will deliver the information which neighboring points are actually necessary for calculating one of the normals involved in getting the central point's normal. I could show you some examples where an "intuitive" calculation fails, and not all of them are based on "evil" polygon configurations. And even if you could (in certain cases there are working algorithms...), it would NOT be faster than getting the normals of the polygons.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 06:10, xxxxxxxx wrote:

Well, actually alreay soved.

But thanks though...

edit: Whoops, didn't recognized the last part.
Yes, building a normalized cross product works. The only problem was to determine the order of the points. In case of this method, you need to have a sorted set of 4 given points. Sorted, because you need to calculate 2 vectors first which are - as you mentioned - CA, DB, or when dealing with Tris: BA CA. When doing this with polygons, everything is fine, since there is an "abcd"-function available.

But I'm still on it. Maybe you're right with your last statement "without looking at the polygons? No!". Thats confusing me though. The script determines if there are enough neighbors within a certain radius available and skips, if not.

But maybe, I'm just getting you wrong? But feel free to post the mentioned examples. Learning from failed stuff prevents from doing the same mistakes

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 06:50, xxxxxxxx wrote:

Perhaps I don't quite understand what your algorithm is like now - I am under the impression that you just take n neighbors and assume that these neighbors form polygons. Essentially... a Newell over arbitrary neighbors?

This will fail when:

- the mesh is malformed (contains edges with more than 2 polys)
- the mesh is folded upon itself (neighbor determination gives wrong sequence)
- the mesh has gaps
- the mesh is two-sided and forms a very flat body

I gather that you somehow replaced examining the real polygons by ordering the surrounding points on just spatial information. That may work for certain types of mesh (well-formed closed polygonal fans, for one...) but may break when confronted with a different topology.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 30/01/2011 at 06:58, xxxxxxxx wrote:

You're right. I'm going to switch over to polygons.
And I agree with your points, especially the last one. If there's a mesh for example behaving like a curtain (with nearly overlapping topology) this method will definitely fail. It would be nice to have a surfacemode then, but in COFFEE...

So, thanks again my friend. You made me thinkover my approach.
But I guess, there will be some more questions next time.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 31/01/2011 at 02:40, xxxxxxxx wrote:

While it's possible in C++ it seems not to work in COFFEE. The Tsoftselection tag is a VariableTag.

In C++ you can read it out like this:

  
Bool MenuTest::Execute(BaseDocument *doc)  
{  
  BaseObject *op = doc->GetActiveObject();  
  if (!op) return FALSE;  
  
  BaseTag *tag = op->GetFirstTag();  
  
  while (tag)  
  {  
      if (tag->GetType() == Tsoftselection)  
      {  
          LONG cnt = ((VariableTag* )tag)->GetDataCount();  
  
          const SReal *data = (SReal* )((VariableTag* )tag)->GetLowlevelDataAddressR();  
  
          for (LONG i=0; i<cnt; i++)  
          {  
              // data[i] is the soft selection value for each vertex index  
              GePrint(RealToString(data[i]));  
          }  
      }  
  
      tag = tag->GetNext();  
  }  
  
  return TRUE;  
}

Basically the same code doesn't work in COFFEE though.

I will update the C++ docu accordingly.

Maybe it's possible in Python too, I haven't checked.

cheers,
Matthias