View Full Version : modo 102 Update
01 January 2005, 01:08 AM
More information has been released on the upcoming modo 102 Update.
modo 102 Update (http://www.luxology.com/modo/102/)
01 January 2005, 03:25 AM
real small update, but looking good. :thumbsup:
01 January 2005, 01:54 PM
doesn't look like a small to me - especially for a service update - looks awesome!
01 January 2005, 02:29 PM
Is the new loop tool like bandsaw? It lookd excellent!
01 January 2005, 08:03 PM
Is the new loop tool like bandsaw? It lookd excellent!
Modo 101 (not the update) already has a 'bandsaw', it's called loop slice and works fullt interactively - absolutely fabulous!
01 January 2005, 08:23 PM
With those additions it looks like modo will be my primary choice for a modeling program when the update lands (since I'm a big fan and abuser of Bridge Tool ;)).
Now, if we could get different cursors for different element selection modes, there wouldn't be any reason not to use modo, at least not for me :)
01 January 2005, 08:47 PM
Looks like a fan fairytastic to me, nothing small about it, thatnks for all your hard work guys, I'm looking forward to it.:thumbsup:
01 January 2005, 02:23 AM
fix symmetry tool looks very good I need it during my work so much!!THX!
01 January 2005, 11:41 AM
im looking forward to the bridge tools..they looks soo gud
01 January 2005, 06:57 PM
modo 102 is scheduled for a January 20th, 2005 release.
I like that.
01 January 2005, 08:24 PM
Is element (vertex, edge, polygon/face) sliding part of the 102 release? The exclusion of this feature is the only thing preventing me from diving right into modo. Also, when will the SDK be released?
01 January 2005, 06:06 AM
u can currently 'slide' stuff along anything you really want using the "element" action center, its bases its orientation to whatever 'element's' u pick's normals. however, u have to select what you want to move, hit move select the element, then move it, but it still works :)
01 January 2005, 06:58 AM
Isn't action centers associated with the currently selected element? The way I understand it, using element action centers will orient the manipulator to the element's normal vector, correct? Thus, if you select another element (of the same type), the manipulator will orient itself to THAT element's normal. The way sliding works is that you have to set what to slide elements on (e.g. either edges, polygons/faces, or curves). Movement of your selected element(s) will then be constrained to these until sliding is disabled (or the element to slide on is changed by the user or by context).
For example, if you set edges as the constraint type and you are in edge mode, an edge slide will constrain the movement of your selected edge(s) along the edges perpendicular to it. Similarly, if you are in vertex mode, a vertex slide will constrain the movement of the selected vertex to the edges that directly connects to it. The same can be said when other elements are used as constraints. I believe that this behavior is different from moving an element with the element action center.
This tool is very useful for tweaking the topology of your mesh without changing it's overall shape. I hope my explanation was clear enough.
01 January 2005, 12:40 PM
this might help if I understand your problem correctly,
try this -
a). activate the element action center
b). select the 'element' (edge, poly, vertice) that you are wanting to move
c). if this 'element' does not have manipulator handles going in the direction that will contrain movement in the direction that you are desiring, then . . .
d). select something in the scene that has a poly or something that does have the manipulator handles going in the right direction
e). go to the tool pipe and click on the 'a' which is beside the 'move'. This will toggle the action center to 'manual'.
f). now click on what ever it was that you wanted to move in the first place. The manipulator handles will be constrained in direction to the selection that was active when you clicked the 'a' in the tool pipe and toggled it to 'm'
let us know if that helps . . .
01 January 2005, 04:28 PM
Not exactly what I was looking for. If I understand your method, Atomman, I have to select the constraining element every time I want to slide an element, correct? With a true slide function, you do not have to select the specific element to slide on- you just select the element TYPE you want as your constraint. Thus, if you select EDGES as your constaining element, then ALL edges will constrain the movement for all elements. In another case, if you select POLYGONS/FACES as the constraining element, than all movement will be constrained to the surface of any polygon the element is a member of. The biggest drawback to the current method is that you have to select the constraining element. In a true slide function, the tool figures out which specific elements to constrain movement based on the (geometric) relationships surrounding the element you want to move. A true slide tool can also automatically scale the component being moved. For example, suppose we select EDGES as the constrainting element (remember that we did not pick an actual edge to base our constraint upon, rather, we set the constraint type to EDGES). Now, suppose the vertical edges of the mesh are not 100% parallel. If we want to slide a horizontallt-oriented edge (or a horizontally-oriented edgeloop) up, this movement will be constrained by the vertically-oriented edges. Also, because of this specific constraint being applied, the shape of the vertial edges are preserved while the horizontal edge being moved is scaled to fit between the constraining edges (please see attached images).
Wings3D and Silo have great implementations of the slide feature.
01 January 2005, 06:54 PM
Now that I think about it, this feature is already available in the loop slice function when it lets you slide the newly-created edges on the edges perpendicular to them. It's unfortunate that when you drop the tool, you loose the ability to slide edges. All Lux has to do is make this feature available outside loop slice and into it's own tool and probably extend it so that it works with vertices.
01 January 2005, 09:03 PM
I suppose you may be able to script edge sliding with the tool.setAttr "poly.loopSlice" "edit"  command if you could feed an arbitrary element to it for input. I wouldn't be surprised to see some of these features people are requesting to be filled in by the community scripters.
The element action center has some problems it seems when trying to slidie multiple edges. I find it's most usefull for arbitrary scale or rotation.
Atomman, maybe I'm not following your post right but isn't it easier to just
1. select element action center
2. select the elements you want to transform
3. activate a transform tool
4. click on any element for the manip. to snap into place, if it's not the one you want click around on any other one. You can keep searching for the right element until you drag or use the manips.
using 'fit workplane to selected' - the seleced being some element that's on the plane you want to slide on and using selection action center may be helpfull.
01 January 2005, 09:17 PM
yes - that would work fine -
my headspace is that usually I am wanting for the handles to be directly over a particular element of the model for snapping purposes. When selecting a vertice element or edge element, often times the handles are at odd angles and make it more difficult to snap to background geometry
01 January 2005, 11:14 PM
I think you lot might just be forgetting a nifty little item called the work plane ;)
Align your workplane to the polygon that you want to slide the edge along, and then you can simply use either move or element move to shift the edge ;)
01 January 2005, 11:39 PM
It's not that simple. If you look at the second attached image, the egde that was slid actually scaled in length as well- the two perpendicular edged not only constrained the edge's movement, but also it's size. Using the techniques presented here, you can slide the edge along the workplane or the oriented axis (in the case of action centers) however, the edge would not scale and thus deform the edges that should be constraining it. Sliding should preserve the overall shapo of the mesh during sliding as it did in the attached image.
01 January 2005, 11:50 PM
that makes sense.
love vertexmonkey btw - i think that site will really grow in the coming months.
01 January 2005, 06:02 PM
"Seamless Integration: New Alias Maya data support, SUBD blendshapes, SUBD creasing, and selection sets improve connectivity to Maya. The RIB exporter allows users to easily render modo meshes with any Renderman compliant render engine. "
Modo 102 is available now through Luxology and its worldwide partners. Modo ships on a single disc supporting both Mac OS X and Windows, and sells for a suggested retail price of USD $895, with a limited-time introductory price of USD $695. It is free for existing modo customers wishing to upgrade to modo 102. To purchase or upgrade, and obtain immediate access to modo 102 via download, visit http://www.modo3d.com (http://www.modo3d.com/) or contact Luxology at (650) 378-8506.
does the yellow part mean we can now export subD surfaces?
as of now maya subD only have 2 options for creasing... one really, since the other one is useless if you tend to render with MR...
*thumbs down to the engineers at alias for not paying attention to the fast growing subD toolsets available now. maya really lack any good subD funtionality :(
01 January 2005, 07:55 PM
Where did you find that quote?
01 January 2005, 08:31 PM
its on the front page of CGNetworks
01 January 2005, 08:34 PM
EDIT: Nevermind :)
01 January 2005, 08:39 PM
Where did you find that quote?
its also on the cgw.pennet.com website.
if thats true, ill order a copy right now...
01 January 2005, 09:04 PM
The only thing correct is some selection set support.
01 January 2005, 09:20 PM
so here is how i (or general public; cg artist more specifically) would read your advertisement:
Seamless Integration: New Alias Maya data support, and SUBD blendshapes, and SUBD creasing, and selection sets improve connectivity to Maya.
although i know a subD export is not likely to be developped anytime soon [or ever], but this is essentially what i am reading from this add.
01 January 2006, 11:00 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.