Is there something like Geometry- and Attachment constraint??

#38

That’s exactly the kind of stuff that ICE does really well at :slight_smile: And would be a lot leaner than generating a ton of geometry or N instances instead of a single point cloud of size N.

#39

Say, for example, you have an airplane fuselage and you want to put some rivets along the various section seams. It would be great to be able to select one of the edges as a path, then invoke your tool, select a rivet model and have your tool create instances of that along the edge. Options would include total number divided evenly, number per point span, or something like that.

An offset value would be good also.

That is my number one issue…how to have the best of Nurbs, Solids and Polygons(SubD’s) modeling in one place.
In several CAD packages it is possible to use a line to do that easily , even with History and follow any later change in surface topology.

#40

Don’t thank me yet. I already have one failed idea under my belt :slight_smile:

Anyways, the idea I had in mind was trying to find a way to constrain an object to a mesh, but use the UV coordinates of the mesh to control the constrained object’s position. Sort of like the built-in surface constraint, but for polygonal meshes.

To better illustrate my point, here’s what can already be done with the built-in surface constraint:

http://vimeo.com/6930811

If the same thing can be done with polygonal meshes, then it would be a lot more flexible, since a polygon mesh can have multiple UV maps and you can lay them out however you please.

So if this hypothetical constraint existed, you would need to specify the constraining geometry and the UV map, and then just animate or position objects by changing the UV coordinates on the constraint.

That’s the idea I had in mind, but it’s not easy to implement. Biggest issue is mapping a point on the UV map to the corresponding position on the mesh’s surface. There’s away to obtain the UV coordinates from the XYZ coordinates on a surface (sort of at least), but not the other way around. At least none that I could find in the SDK.

Thoughts? Ideas?

#41

I have no thoughts on how to achieve that, but if you can pull it off you’ll be my hero of 2009.

#42

I think an issue could be that it’s not a 1-to-1 relationship between uv and xyz .
an xyz coordinate maps to only one uv coordinate per uv set, but not the other way around.

Then again, you could just pick the first xyz the inverse lookup finds, assuming the uv has been built in a way anyway that no multiple xyzs are intended:D

The inv. lookup will be surely tricky to write though, especially when it comes to subdivs!

ps- ShaderOp I hope U don’t mind I added your addons to my resource listing website rray.de/xsi. Let me know and I’ll remove them right away!
ps I’ ve just read about curvature in your post, this reminded me some curvature related stuff can be found here too rray.de/xsi

ray

#43

Of course I don’t mind! If anything, I’m grateful for all the work you’re doing to keep that list up to date.

#44

Wouldn’t this approach limit the “randomness” to only where a UV existed? It seems to me that unless the mesh was extremely dense, it might be pretty easy to spot the UV pattern. Imagine a grid of 8 by 8. If you then applied some rivets to that based on the UV map, would they end up scattered along the UV lines only?

#45

No, that shouldn’t be an issue. At least it wouldn’t be if things work out.

The only feature I will not attempt to touch is having it work with live subdivided surfaces. The workaround would be the same one suggested with the geometry constraint plug-on, and that is to apply the “mesh subdivide with center” operator to the mesh, and then use the resulting object as the constraining mesh. I hope that would be a reasonable compromise.

#46

just realized—I never tried this, but there could be a chance things with subdivs might work out transparently when you use CGeometryAccessor with the current subdiv level as the in_subdLevel parameter.
(This is assuming it works as advertised and I didn’t completeley misunderstand the sdk docs)

The next problem then would be to find a good data structure for the uv->triangles lookup

#47

I haven’t tried it myself, but that’s not the problem really. The issue is that I’m relying heavily on the Point Locator API, which doesn’t have any provisions for querying for point locators on the subdivided mesh. At least none that I can find.

Regarding that, I think I’m on to something:

http://vimeo.com/6977085

The video above shows a very naive implementation of a scripted operator that constraints an object to a point on the surface of a polygonal mesh determined by the U and V coordinates on the mesh’s texture map.

It’s working well I think. But it will not follow the surface if the constraining geometry is deformed. And the data structures were pre-generated using an external python script.

I’ll try to finish it as time permits, but I doubt I’ll have any time to spare for the next week or so due to some crunch time coming at work.

That said, I think it looks very promising so far. Fingers crossed :slight_smile:

#48

I haven’t read the whole thread so far but it’s easy task with the Object To Cluster constrain.
Just select the object to constrain, then the object with component to constrain, and select the component (all is suggested in the mouse status line)
Then adjust the Tangency and the normal. That’s all. It’s included at leaste since v 4.2 (when I started with softimage)

#49

Object to cluster will only take a component or the average of several as in input.
Constraining to a mesh and offering access to barycentric interpolation on face is a whole different deal and isn’t possible out of the box (outside of ICE that is, which doesn’t offer supported kine access yet).

#50

Looks good so far ShaderOp. Keep going

#51

So what happens if the input U/V coordinate falls on an empty section? Maya’s rivet setup goes nuts and it defaults to an odd location. Same if you cross over an empty section back to a section that has UVs laid out in it.

Just wanted to see what your thoughts were on this and whether the script take this into account.

Eric T.

#52

if you use the UVs as direct input, you look for the closest boundary.

#53

That’s a valid concern. Unfortunately, I don’t have a concrete answer at this stage. Aside from the small test posted earlier in this thread, all I have is an idea that seems to make sense to me, and it should work reasonably well in the scenario you’ve mentioned.

Thank you. Any chance to get out of the echo chamber and bounce ideas around is highly appreciated.

I should mention that’s it’s no longer a script :slight_smile: I’m writing this one as a compiled plug-in, and it’s taking me a while to get back on the C++ saddle. As I mentioned before, things are a little busy at work these days. But I’m still able to put an hour or so of work into this every day. If anyone feels like geeking out, you can view the source code at this repository hosted on bitbucket.org.

#54

@Jaco: Cool. Wish the rivet script did that. Would have helped a lot while I was back in school.

@ShaderOp: Glad the discussion helps you. It’s great to see more people building plug-ins and scripts for Softimage. Look forward to seeing more of your work.

Cheers,
Eric T.

#55

Hi everyone,

I think I have a working solution for the UV geometry constraint. But I would greatly appreciate some feedback at this stage.

The following video shows a cylinder with a nontrivial texture map and a null constrained to the surface of the cylinder, with its position controlled by the UV coordinates.

http://www.vimeo.com/7118685

Shown above is the behavior when the UV parameters move across gaps in the texture map. I think the behavior is decent given the irregularity of the map. But that’s just my opinion.

If you guys (and gals) think it’s usable, then I can finish it up, as there isn’t much work left to make this into a proper plug-in. Otherwise, I think I ought to cut my losses and move on to something else.

Either way, it was an interesting ride :slight_smile:

#56

It looks good to me. would it have tangency and normal controls too?

#57

No, I haven’t worked on those yet. Aligning to normals is doable, but I’m not sure about tangency.

These two features aside, only thing missing right now is the command to wire up the constraint. I could have that done and release the plug-in by tomorrow or the day after. And depending on feedback, figure out a sensible way to implement normal and tangency controls. I would rather do take that route than keep hacking at it until I get all the features in.

BTW, I don’t have access to 7.0, and I don’t know if plug-ins compiled against 7.5 are backward compatible with 7.0. I also don’t have access to a Linux machine, and even if I did, my subscription is Windows only. So if anyone can volunteer to build binaries for 7.0 and Linux, I would be very grateful.