I really like the interface David, especially how the PWS could be split up into separate scrollable areas or as you put it ‘folder bars’…neat idea.
Colour coding (slightly tinting) the adjacent timeline would certainly add to the readability, in fact they should implement this idea regardless of whether they would use the folder bars.
Some mock-up!
If had to use that Aqua interface for more than an hour. . . I think I’d friggen explode. White. . . on off white. . . with more white. . . oh and a few gum drops.
Throw some of that brushmetal in there David. From the new Finder.
Nice mock-ups.
I have already suggested colour coding for the pws. I guess that it wouldn’t be to hard to implement. The idea for collapsing things is inspired. They are going to implement that kind of thing for the menus anyway so they should be able to hack it. An alternative would be to have it so that filter tabs could be ripped off making their own detatched pws’s.
By the way, has anybody noticed the menus that pop up when you right click on the pws scroll bar or the handle that separates the pws from te main screen? I only found them just the other day. I wonder what else is lurking around that interface?
After doing a looong render I would like to see a shut down computer when complete function.
Can’t you just configure your computer to go to sleep when the cpu usage goes below a certain amount for a period of time?
jmcalpin–2. Extrude leaves patches where they come from so they are not good for adding detail to a model. Fix it so that a hole is left behind or make a new tool… say bevel that allows this.
It’d have to be a new tool, or maybe an extra extrude mode of some kind–like a “shift +” sort of thing. It’s nice to have a basic extrude that doesn’t do anything automatically–AM tends to make a really lame job of guessing at just what you’re trying to do with some of the “smarter” tools and plugins. . . .
But yeah, that would be incredibly useful. It’d feel sort of like subd modeling.
How about the ability to close a spline into a hooked spline. If you have done any subdivision modelling this may sound familiar as it’s basically subdividing a polygon.
Only thing is, in a polymodeler, you can keep subdividing and subdividing where necessary.
The advantages?
You can close off more awkward splines and add a lot more resolution if necessary
AM subdivision of patches is NOT the same as subdivided polygons - patch surfaces are curved or straightened BUT you are the one in control and you can add porcelain to create further smoothing.
This might allow AM models to have the necessary resolution WHERE necessary to allow the use of Z-Brush as an add-in technology
Disadvantage - Hash would have to improve how hooked patches render at render time
If this sounds stupid please say so, I’m just thinking aloud.
1- The ability for Materials to influence hair or hair colour like the way image maps can at present.
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’m not sure Z-brush and AM will work to AMs strengths unless we start to produce mesh heavy models.
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.
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.
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??
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.
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
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…
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
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.
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
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! 
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
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.