Feature Requests

#130

The ability for Materials to influence hair or hair colour like the way image maps can at present

They already can… Have you seen the Hash tutorial/explanation? They even include a project file.

#131

2- In the light of Z-Brush and the impact its having on the future of 3D texturing (like Photoshop did with Image Maps), how about modifying or allowing Materials to be influenced by decals so that you can mask areas out (or in). Z-Brush does work best with mesh (poly/patch) heavy models but some materials can sculpt surfaces fairly heavily.

I don’t think that heavy meshes are necessary if Hash would implement sub-pixel displacement maps. Since patches are already infinite resolution, all you have to do is modify what is made up at render time and poof! You’re right back in the ballgame with a low patch count.

Would perhaps again make Hash patches > sub-ds.

#132

Originally posted by zero2zillion
They already can… Have you seen the Hash tutorial/explanation? They even include a project file.

Hi Zach! I get what you mean (I haven’t looked at the project file) and my first trials for Stone Scales on top of a material had the colour picked up but it didn’t pick up the different nuances (dent/crumple/scales etc etc) that the material itself gave the patch mesh underneath.

Do you get what I mean or should I post an image reference?

Originally posted by odinseye2k
I don’t think that heavy meshes are necessary if Hash would implement sub-pixel displacement maps.

LOL… that’s why I made a feature request! Hopefully someone from Hash or someone Hash takes seriously reads the feature request sticky and makes suggestions forward!

Originally posted by odinseye2k
Would perhaps again make Hash patches > sub-ds.

Wouldn’t that be great? I’m NOT a programmer and neither am I a Technologist but does your reply about sub-pixel displacement maps take in the problem of the effect Displacement Maps have on hooked patches??

#133

LOL… that’s why I made a feature request! Hopefully someone from Hash or someone Hash takes seriously reads the feature request sticky and makes suggestions forward!

I think it’s an idea that’s been floating around for awhile, even amongst the Fellows if I remember my semi-recent history correctly. It seems like a pretty logical step to evolve with some of the tricks the other guys have been using (mathematical scripting, CP weighting, UV editor with patch-splitting capability).

Wouldn’t that be great? I’m NOT a programmer and neither am I a Technologist but does your reply about sub-pixel displacement maps take in the problem of the effect Displacement Maps have on hooked patches??

That one was a little flippant - I have a fascination with the history of technology evolution and the competition that very naturally goes with it (although a parallel Hash/Catmull story would be very interesting). In talking about sub-pixel displacement, I assume that any algorithm developed would necessarily work for all types of Hash patches - including hooks, 5-pointers, 3-pointers and 4-pointers.

#134

if there would be sub-pixel displacement maps it would be fantastic to be able to paint on it like on the hair, so that there is automaticly a map on the model on which you can paint directly in shaded mode or so

#135

1- copy paste grooming info (include copy flip and paste)
2- copy paste relationships.

Just create a model with fur, groom and then try dragging a rig with constraints into it…

I now know that really, I should create a new model in a rigged mdl if I want to use a pre-made rig…

#136

Here’s an idea for a new constraint that I think might prove handy.

http://www.sonic.net/raillard/hash/spherical_translate_limits_constraint.gif

Currently we have a Translate Limits constraint that allows a bone to rattle around inside a box, defined by three maximum and three minimum parameters, in the X,Y, & Z planes, respectfully.

This new constraint would be similar, except it would keep the constrained bone within a ball. My picture shows how it might work. I show what would happen with three possible settings.

In the first case, the minimum diameter setting is set to 0 and the maximum diameter setting is set to 6 cm. This would allow the constrained bone to be translated anywhere inside a 6 cm. diameter sphere.

In the second case, the minimum diamter setting is set to 4 cm. and the maximum diameter setting is set to 6cm. This would allow the constrained bone to rattle around between two spheres. It can go no closer to the origin than 4 cm, and it cannot go beyond 6cm.

In the third case the minimum diameter setting and the maximum diameter setting are both set to 6 cm. This would force the constrained bone to stick to the surface of a 6 cm. sphere.

I don’t know how difficult it would be to program such a constraint, dumb artist that I am. Still, I’m fairly certain it would be very useful. Consider the Setup Machine rig. Currently, the SM rig uses a plain old Translate Limits on the Bicep control bone. The underlying shoulder geometry bone (which is hidden) has an Aim At constraint, which points to the Bicep control bone … hence, you can control two bones, the bicep geometry bone and the shoulder geometry bone, with this one control bone. This is sweet. Why hassle with two bones if you can use just one? Well, actually there is a reason why you might not like this. Since the bicep control bone is free to bounce around inside a box, it no longer perfectly superimposes the underlying bicep geometry bone, whose origin has to move in a sphere defined by the length of the shoulder bone. This is not really a major deal … but it does produce a bit of wiggy behavior within the automatic elbow pointing rig, from time to time. To the best of my understanding, this is the chief reason why the Setup Machine offers the option to NOT install an automatic elbow control system. However, it cannot be denied that an automatic elbow managment system is a nice thing to have! Anyway, this is my chief gripe against the SM way of shrugging shoulders, and why I prefer a visible shoulder bone. If this new spherical translate limits constraint were available to us, then the SM way of doing things would instantly become the preferable alternative for everyone. A visible shoulder bone would become a thing of the past.

Okay. I’ve made my case. Feel free to throw flowers or bricks at it.

Respectfully,

Carl Raillard

#137

Sounds really clever! But in a way, can’t you do this with “constrain to surface” and then choose a sphere? Or does constrain to surface affect one spline on a surface only? Forgive me if I’m being thick, rigging isn’t something I have a full grasp of.

#138

My two cents can be best summed up in the image below

http://sonofpat.bravehost.com/PWS.jpg

This can be summed up in the following way
1: The ability to lock a group in the PWS by toggling the lock icon
2: The ability to toggle between wire frame and shaded mode on
groups instead of the whole model.
3: Toggling visibility PhotoShop style in the PWS. In addition, the
visibility status of a group must be saved when the project is closed.

These came straight out of wings and all speed up modelling without any big change in spline technology per se.

Luv

Pat

#139

Hello, Hoochoochoochoo.

Well I can think of a couple of reasons.

A surface constraint requires two bones; one bone rides on the surface, and the second bone serves as a pointer. Its job is to control the first bone’s placement on your chosen surface. In other words, you are orchestrating the movement of bone1 by means of bone2. You can’t just grab bone1 and move it directly, and expect it to remain on the surface. If you do that, you’ll just add offset channels to the surface constraint. Not exactly a hard and fast limit! :wink: I guess what I’m saying is that a surface constraint is really a position-me-on-this-surface constraint. My proposal is for a genuine translate-limits constraint. I want it to restrict bone translations, not just guide them.

Also, I don’t want a big honking ball at every joint where I might wish to employ this new constraint. I’d be willing to waive this gripe aside if Sonofpat’s idea of group visibility parameters became a reality.

Pat: Your group suggestion is TERRIFIC! :bounce: Just imagine hiding & unhiding groups without going into muscle mode! Man, that would save time!

Sincerely,

Carl Raillard

#140

to prevent the user from having to go to great lengths to try to report a bug and have them say that either they couldn’t replicate it or that your instructions were too avague, why don’t they have someting that is internal recording the users action (probably exists already for undos) and then when there is a crash the history along with other necessary details, such as stack data etc, be sent off to hash so they can see exactly what the problem is. Really this is just like the feature that MS has in winxp. Obviously this is only for crashes and something that is done in some global exception catcher.

#141

You know, the more I think of it, the more I think my new constraint idea is not gonna happen. I’m no programmer … but I get an uneasy hunch that a Spherical Translate Limits constraint would be a major undertaking. It’s one of those things that’s easy for a human brain to understand, but (like collision detection) I think it’d be hard for a computer to grasp. I’m guessing it would involve differential equations, or something like that, to keep the bone inside the spherical space. Rocket Science stuff.

I’d still love to have this new constraint, don’t get me wrong. But … well. It’s foolish to expect a Nasa-level guidence system for a bone in an art program.

Sincerely,

Carl Raillard

#142

Actually, I wouldn’t have thought that it would be all that difficult to impliment. A sphere is an easy thing for a computer to understand. The only hard part as far as I can see would be working out how the bone would react to hitting the limit on an angled curved serface. It is probably worth asking anway if you think it would be beneficial. Maybe the Anzovins would have something to say on the matter if you asked them?

#143

Like Carl said, this would probably be pretty math intensive…but couldn’t it be done using “Expressions”?

Maybe my brain isn’t working right today, but if you put translate limits all the way around a bone (min and max all set to the same distance on x, y and z) it seems like it would accomplish the same thing.

I might not be right…I’ll have to put a project together to illustrate what I mean when I get a chance, probably not until extremely late tonight.

EDIT:

Doh! Okay, now that my head has cleared (and reading the previous posts) I understand that the translate constraints I suggested wouldn’t fit the bill. Sorry about sounding so dense…I still think there is a solution. How about a bone anchored at its base with the scale set to a range? That would give you a sphere with the kinds of limits mentioned. It’s probably worth some experimentation…

#144

Okay, it took me a while to actually mess with it, but here’s my interpretation of a spherical constraint that you can impose limits on and such (in the attached zip). When you open the “spherical.prj” project, it should have “Action1” open and ready to mess with. What you see is “Bone1” as the bone that defines the sphere, “Bone2” as the bone you would attach any geometry to and “Null2” (at the intersection of “Bone1” and “Bone2”) which is the manipulator…there is also a “Null1” that is set so that it isn’t seen which helps drive this.

When you move “Null2” around (“Bone2” can be moved independently as well, but the constraint only works by manipulating “Null2”) you’ll see that “Bone2” follows while remaining within the area defined by “Bone1”. You can move “Null2” outside of the defined area, but “Bone2” will still remain inside. You can adjust the area within the sphere that “Bone2” can occupy by changing the setting on the “Translate Limits” of “Null1” in the “Pose1” relationships folder. To make “Bone2” able to operate in a larger sphere, you’ll need to increase the maximum translate limit for “X” to something above zero, to keep “Bone2” from reaching the center of the sphere, you have to change the the minimum translate limit for “X” to something higher (-14, -13, etc) than “-15cm”.

  It is my humble attempt at solving this problem with the tools I understand, I hope it helps.
#145

Hello!

Thanks, Itsjustme, for spending the time investigating this problem. It’s certainly a fascinating rig.

It’s not quite what I’m after, though. The fact that bone2 is distinct from Null2 is the deal-breaker, for me. What you’ve cooked up is very similar to a Surface Constraint (one which uses a ball as surface, except you cleverly employ bone1 instead of a lathed sphere). You’re still positioning bone2’s placement on the ball by means of another bone (Null2, actually). I love how elegant you’ve made the adjustment of bone2’s freedom, just by adjusting Null1’s Translate Limit’s constraint. That’s cool. Still, my main need is to position everything with one bone, not two. Essentially I want Null2’s freedom to be curtailed. Picky, aren’t I?

Consider my Anzovin shoulder-rig example. The elbow-pointing paraphanelia is directed by the visible Bicep Control Bone. By analogy, this visible Control Bone would be Null2, in your setup. Since it’s still free to pull free from the end of the shoulder, it’s going to carry the elbow pointing stuff with it. This is exactly how a discrepency is introduced, between the control bone and its underlying geometery. This is how unpredictable behavior creeps into the system. Of course one could set it up so that the elbow control mechanism is directed by bone2, instead. But then bone2 would have to be visible all the time. This means you’d have two Bicep Control Bones … and Null2’s function would be reduced to that of “Shoulder Pointer.” Really, it would be simpler just to keep the shoulder visible. This is one of the reasons why I favor the Egg rig, because the shoulders are visible, and the elbow pointers function more precisely as a result. Still, I do envy the simplicity of the Setup Machine Rig. To be able to adjust the shoulder and upper arm with one bone, instead of two, is neat.

So for my purposes, your setup doesn’t quite cut it. Still, it’s neat to study. Joe Williamson needed something like this, for the knee of his Hunter model. Maybe it’ll be useful for him?

I’m definately keeping a copy of your rig on my hard drive, Itsjustme. If I ever need an object to remain in a spherical orbit, I’m going to use this puppy.

Sincerely,

Carl Raillard

#146

What you’ve cooked up is very similar to a Surface Constraint (one which uses a ball as surface, except you cleverly employ bone1 instead of a lathed sphere).
Well, this version of a spherical constraint isn’t like a surface constraint in that a surface constraint would keep a bone on the surface of a sphere while this keeps a bone inside the area of a sphere with the added option of limiting the percentage of that area as well.

Still, my main need is to position everything with one bone, not two.
In order to make a spherical constraint I think you’ll have to use at least two of something (unless you use a single bone that defines the sphere like “Bone1” with CP weighting I’m guessing, but then you would also have to vary the scaling of that bone so that it doesn’t operate like a surface constraint). Whether one is a null or a bone doesn’t matter, you’ll have to have a bone/null to define the center of the sphere. I used “Bone1” to define the center, “Bone2” to attach geometry, “Null1” to limit the area of movement inside the defined sphere (which can exceed the length of “Bone1”) and “Null2” to manipulate the rig.

Essentially I want Null2’s freedom to be curtailed.
You could limit “Null2” with a box-shaped “Translate limits”, it would keep the manipulator close to correct…except on the corners of the box that exceed the radius of the sphere. For me the fact that “Null2” can move outside of the defined area wouldn’t cause me any grief since the bone I want constrained can’t move outside the area I’ve decided on…actually, you could move “Null2” farther away with an offset on it so that the controller is easier to grab instead of reaching inside of something like a shoulder to manipulate it.

If you’re going for just a bone that is constrained to the surface of a sphere, you could use a bone to define the center of the sphere (like “Bone1”) with a child bone set to “Attach to parent” (let’s call it “Bone1/2”) then add another bone like “Bone2” to attach the geometry with a “Translate to” constraining it to “Bone1/2”. That would give you the spherical constraint, but you lose the adjustable area within the sphere that the original version has (I have attached a ZIP with a project to illustrate…the manipulator is “Bone1/2”). If you’re not worried about rotatation of the bone attached to the mesh, you could eliminate an additional bone.

I’m positive that there are other ways to accomplish what you’re shooting for, this is what I came up with by using the existing tools that I have a pretty good grasp of…there is probably the ability to set the “Translate limits” constraints as a sphere using Expressions, but I wouldn’t know the proper syntax since I haven’t messed with any of that yet. I’m thinking that the equation necessary can be found on the internet…I’m also not much on math. You could probably use an expression to vary the scaling of “Bone1” to stay within a radius, but, once again, I wouldn’t know the syntax etc. to implement it.

As for how the rig in “spherical.prj” would work inside of either the Raf or Egg rig, I’m only familiar with small portions of each…I generally roll my own, but it would be worth some experimentation in the future.

#147

You’re quite right. Your rig does have that advantage. I guess it reminded, a little bit, of a Surface Constraint because it involves two bones (surface and pointer).

As far as boxing Null2 in with a Translate Limits constraint, that’s not going to work. The problem with the aforementioned elbow pointing mechanism is due to the fact that the bone that guides the shoulder is not EXACTLY superimposed on the underlying geometry bones. Rigs are similar to lawn chairs. The looser they are at the joints, the more prone they are to folding or twisting in the wrong direction. Even a slight discrepency is enough to create wacky behavior.

I should mention the Setup Machine rig is fine, as is, for characters with insubstantial shoulders (e.g. Mickey Mouse). But if you’re using it to rig the Incredible Hulk, and you want him to shrug his shoulder in combination with complex arm swings, then I’d advise telling the Setup Machine NOT to install the elbow guidance system.

Thanks for the new zip file, Itsjustme. I’ll snatch a look at it, when I get a chance.

I’m intrigued by your suggestion that a Spherical Translate Limit might be accomplished by means of an Expression. I haven’t had much luck with Expressions, though. Every time I’ve tried to create an Expression – any Expression – I couldn’t get it to work. The dang things hate me! :curious:

Sincerely,

Carl Raillard

#148

Since there isn’t a whole lot of documentation for Expressions yet, I think everyone is in the same boat for the most part with them. I tried putting an Expression on a limit, but it didn’t appear to be an option. At this point I don’t know what can or can’t use an Expression without some trial and error. Then I’d still have to get the syntax right…and so far I’ve gotten a lot of syntax errors when I tried some experiments.

I haven’t really used Raf’s or Egg’s setups I wouldn’t know how to address anything specific in them…from what I’ve looked at they’re both very nice. Can you show an approximation of what you’re trying to achieve? Maybe somebody here or the Hash forums would know how to accomplish it.

#149

I finally took a good look at the Generi-rig for Maya (with the learning edition). I see the charater used everywhere and now I know why. The shelves feature and the trigger UI sure make selections a breeze. I would like to see something like this. Or something like this just for organizing a custom PWS.

http://www.andrewsilke.com/generi_rig/generi_rig.html