To have better control over surfaces? surface degree etc.
for instance, moveuvn is really outdated and not really nice to work with while point pulling is essential in surfacemodeling.
right now for serious surface modeling the only option is either alias or icem and both are unaffordable, would be nice to see rhino stir up things,…
Sabino,…
Agree, Move UVN and Match needs a lot of improvement.
Hi Lagon - I know of some things that people (and I) want, but if you can be as specific as you can about what these tools lack, that would be very helpful for the future.
thanks,
-Pascal
Hi Sabino, Lagon, all- - it is probably not as smooth or slick as you would like but there are a few things that you can do -
in V5 & 6 - DragMode set to ControlPolygon - locks point dragging to the adjacent control polygon lines. Works better in V6/WIP. Ctrl-key down forces a normal move in this mode.
in V5 - GumballDragStrength to gear down mouse movement when dragging (especially control points).
in V6/WIP
DragStrength control that gears down all drag operations.MatchSrf has History (one edge at a time)MatchSrf does not require an edge, you can match to anyplace on a surface-Pascal
The matching functions need to show measurements ie deviations, otherwise they are useless.
G0=mm
G1= ° ’ ''
G2=mm
G3 = ° ’ ‘’
Furthermore a SWAP button should be added to swap the matched surface with the reference from within the command. This is useful if you try to control the matched surface by manipulating the reference.
Realtime control of the reference side is also needed, so the matching updates as you manipulate the reference, while showing the deviations and measurements.
Zebra-shading has to work while you are running the matching command.
Regarding surface manipulation a tool is needed to move control points along their tangents, in normal direction or locked into an axis direction of a construction plane or the WCS, with the option to choose single points or complete rows in either u or v direction.
A proper surface extrapolation tool is also needed, with the to option to extrapolate a single edge or an endpoint of an edge so the other end stays in place.
A delta value for those functions is a must, as you gain immense precison using it in combination with the deviation measurements from the matching tool.
Tangents, normals, and controlpoints need to light up when used to give visual feedback.
I hope that some of these functions make it into Rhino V6, as they are key for aprofessional modelling workflow and surface control.
Best regards and thanks for all the hard work you guys put into Rhino!
This.
This.
Pascal, if you have time to spare, maybe have a look at what one can do with these tools. Once you can do this, you can model almost any product with bezier surfaces in an easy and, more importantly, controlled(!) fashion. As far as control point manipulation is concerned, regarding UVN and other methods, this tool, while having evaluation switched on on any curve or surface, is worth everything, and then something.
Maybe intellectual property is not getting in the way, maybe patents have expired, maybe some of the above mentioned issues - having visual evaluation and numerical evaluation switched on while manipulating, moving or matching would already be a great step forward.
Yes thank you, i was about to write a whole essay about align in alias.
Ive been a rhino user since 2001 now and if i get any tool see a huge update it would be match surface getting up there with alias align.
Id say in my alias workflow align is probably the most powerfull and most used tool.
My top priority in matchsrf would probably be being able to adjust the amount of tangency and curvature (and please not with parameters only) with something interactive.
Thanks for that, will definately check that out,…
any update on loftcrown btw?..
The matching functions need to show measurements ie deviations, otherwise they are useless.
I would go even further. Why not implementing a visible matching analysis based on deviation graph. I’m using Icem Surf as main modeller and from time to time I manually match surfaces in case when algorithmic matching fails for some reason. And without offending here, but Surfs Matching capabilities are much more diverse, because they actually provide a lot of different kinds of matching.But still, sometimes you need to tweak it manually by pulling cps. Its also never about perfect g1/g2 matching but more about living inside acceptable tolerances. Sometimes g1 blends look better than g2. Why is everybody telling you need to have g2 or higher? Well, everybody has its own view but implementing something like this would be really useful in Rhino.
I also think this is not so difficult to do, since I coded one for myself, but it would make much more sense if this is integrated into native Rhino functionality.
A better example:
Even though the surface in this example hasn’t got a good controlpoint layout, I was still able to match G1 with 8x5 controlpoints. Because of the size, G2 would not made sense anyway (<1mm). It is more important to reduce cp count in order to get a smooth shape, so that the eye doesn’t see a sudden change in curvature within the surface, because G2 can also unsmooth a surface. It also possible to match G2 but loosing G1, This is when curvature is equal but tangency align fails. Anyway an algorithmic matching produced a much worse result, and in Rhino the cpcount would have exploded here. But because of having a deviation analysis, I was able to match it manually ways better…
Yes!
Philip
Hi Pascal,
apart from the linkes in my comment above, here are two illustrative images to show some of the functionality of the match tool in conjunction with persistent diagnostic shading or persistent continuity analysis. Really, like other commenters mentioned, it’s the persistence of analysis tools while working on curves and surfaces that would be very much welcomed. In any case, it’s much appreciated that you and colleagues are listening and responsive to users.
Thanks all - one thing I get is that interactive controls and analysis are a big part of this as opposed to firing off individual commands.
-Pascal
Controling Spans and Degree directly within from withing a matching command would also be helpful. This way you can directly react to the deviations.
The delta value I was talking about, means a step size btw.
For surface analysis a Zebra-shader with fixed directions would also be needed.
The current shader in Rhino allows only vague checking of continuity at the edges, but not for actual flow of the surfaces.
Only a Zebra-shader with for example a fixed X, Y or Z axis projection direction, while moving the camera allows you to analyse your surfaces properly, as the lighting conditions and direction can be exactly reproduced each time. The Rhino Zebra-Shader is all over the place.
And one more thing: Please everybody lets not get too fancy. All the ideas around here are great and I would love to see them all getting realised. But the truth is that you cannot hope for Rhino to compete with the leading edge in Class A-surfacing. Those companies have developed those tools for more than 20 years.
I´m an ICEM user myself, and I know how great and important those tools are, but I doubt that McNeel has the knowledge to implement all of this, let alone in the next couple of month.
My point is: Just give us users a robust matching tool with precise measurements and a couple of interactive options. That would be a giant step forward for Rhino …and a realistic one.
Best regards
I don’t think there is too much danger of that, at least in the near term.The upshot is that for V6, which we would love to pin down and soon, there is not more than what I outlined above for MatchSrf . Baby steps, but it is pretty handy - you can match a surface with History and adjust it with Zebra on and have the match maintained.
http://www.screencast.com/t/ELB0EuKZ5
http://www.screencast.com/t/bA3MGPjKb5
-Pascal
One man’s opinion on version 7:
Modleing improvements…PERIOD
Nothing else. Now that core changes are solidified and us PITA Mac version people are satiated, etc … modeling improvements.
Surface
Sub-D
Match, etc
A wiz bang effort to throw everything you’ve got at nothing other than the biggest set of modeling improvements your users have ever seen.
I think users will go ape over that. But then, I could be wrong…
@Pascal for the blendsrf command is it possible to add a check box to have the handles created so that the angles matches to the opposing points in addition to current shape curves being perpendicular to the surface edge or parallel to the surface isocurves?
When making multi blend many tips starts from setting this up first.
Just another thought when moving control points, if there are restriction of movement when moving the point goes to a point where curvature cannot be kept, that might be useful.
Looks great so far!
The first video is good example of the zebra shader. The zebra-lines have to stay in place!
I would really appreciate fixed X,Y and Z projection direction to choose from, that is an important feature for surface evaluation. Please implement that option.
Plus as stated above, ad a little tag showing the deviations inside the matching command pop up, that tells us:
G0=mm
G1= ° ’ ''
G2=mm
G3 = ° ’ ‘’
The software is calculating the deviations anyway, to know where and how far to move the CPs of the matching side, so you can as well show them. The matching tool would really make a big step forward this way.
With that feature and the improved Zebra shader, I would be happy with the matching capabilities for V6 then!
I agree with this notion 100%. Rhino’s core function is modelling and it does seem lacking in some areas compared to other packages (admittedly they often cost much more than Rhino so the comparison is perhaps unfair).
Although I’m sure I’ll buy into v6 when it is eventually released and find much to like, nothing I’ve seen so far particularly excites me (the stuff Pascal has highlighted in this thread does look good).
The apparent focus on adding improved rendering is of little interest to me - rendering is one area where Rhino is very well served via plug-ins, whereas advanced modelling is now lacking thanks to Autodesk. It would be great if McNeel addressed this.
I was wondering if it s possible like in VSR to project a curve on a surface which is originally single span and the resultant on the surface is also single span ?
I find that sometimes when I project or combine 2 ortho crvs to create a 3D crv there are way too many points. VSR was doing a great job of keeping the curves as simple as possible
thanks
Alex
