View Full Version : how to move group of faces on theirs normals

12-07-2011, 03:33 AM
this is a BIg question, something that i never succed to do, and never find a pluggins.
how can i move the greens faces of the objects ( number 1) to reach the result of the blues objects; without having the edges of the reds objects,
in on click.
i've tried severals things but not with a clean result ( bevel, multishift, point normal move....etc)

someone have an solution ????

12-07-2011, 04:33 AM
With the circle example you can use constrain scale to just shrink the hole.

With the 'L' shape example, I'm not sure...I've wanted something similar for a long time. The tools you mention can do what you need but you will have to merge some polygons afterwards. By using multishift with 'contour' or 'contour2' selected, the polygons will be shifted along their normals, then you can merge the extra polygons by selecting and using Shift-Z.

12-07-2011, 04:56 AM
Heheh, that's classic LWModeler problem for not having gizmos (X/Y/Z handles) and not being able to work with local/parent/world coordinate system. You cant' do it without some special plugin, natively i'd do as biliousfrog says use multishift and then delete excess edges.

Maybe "Translate plus" tool would be able to do it after some fiddling with modes and selections but it's so cumbersome to use and so badly designed that you'd give up on using it very soon anyway :).

Gizmos/workplanes are missing stuff in LWM which makes us to use all kind of workarounds for years and years ;).

12-07-2011, 06:23 AM
well, obviously the problem will not be easy to solve.
the constrained scale, is ok with on circle, but not 2 or 3 at the same time, and multishift create more edges .
Even if this not an obstacle, with somes tricks, it will be nice if lightwave can do this sort of things.:(

Oedo 808
12-07-2011, 08:11 AM
For the circular loops you could use the right mouse button with (Modify>Translate>More) Move Plus (Bizzarely listed as Translate in the shortcut menu should you want to assign a key), though it's not much good if you need to be precise through utilizing the numeric panel. Move Plus + RMB works fine on circular loops and does pretty well in most cases on gently curving loops if you don't need a 100% match to the normal direction. However it really begins to fall down the sharper the angles get, so it's no good for the boxes, though selecting and deleting the surplus edges after using Multishift (use Remove on 9.6 and earlier) as suggested above should only take a moment.

Quite peculiarly, on a loop that has only right angles, Move Plus seems to work fine. Perhaps I'm missing something. :question:

12-07-2011, 12:19 PM
Yeah until Modeler gets some love and comes out of the stone age looks like you are stuck with Multshift - would be my choice. Or in certain situations where I don't mind dealing with the tool - Translate Plus.

12-07-2011, 06:38 PM
Jerome the answer is Multishift; after you use it just expand your selection, "Select outline edges" and "Dissolve" and those edges won't bother you.

The "Move Plus" Right Click function will work for your second object since it's a closed loop and will add no edges, but not for the first one

Anyway, Multishift options (Shift)

Point Normal = Point Normal Move
Local Point Point Norms = Move Plus' right click
Countour = the stuff you want ;)

12-07-2011, 11:59 PM
thanks for all this advices.
there is always a way in lightwave to do things.
but honestly, the situation is different with 10 or 20 or 100 objects to do.

12-08-2011, 03:14 AM
Certainly is. But believe it or not Multishift is a better solution than any of the tools I have seen anyplace when it comes to moving on normals and the options for this. It is the one tool I have longed for when using other apps even though I think Modeler is in much need of love.

Don't forget that you can store profiles in Multishift for using again on multiple objects.

That will help.

12-08-2011, 05:49 AM
Jerome, check the little video.

Sure it's not lightspeed, but if you have buttons or shortcuts in place and you are able to see all objects and they all need the same shift ammount you can do it somewhat faster no?

(Select, Multishift, commit, Expand selection, Select Outline Edges, Dissolve.)
Ahhh Photoshop Actions would be nice wouldn't they? ^^


12-08-2011, 06:29 AM
nice demonstration Probiner.
i haven't given it a thought :thumbsup:

12-08-2011, 07:07 AM
point normal move in modeler. Do a search in edit menu layout.

12-08-2011, 07:20 AM
He wants polygons' normals not points' normals :p

12-08-2011, 09:25 AM
I thought "point normal move" as well. I always thought it moved on the poly normal for some reason though. Its definitely a handy tool either way.

If it doesn't, someone should write "poly normal move". ha.

edit: bummer. it does move on the point normals.

12-08-2011, 01:53 PM
hmm.. it seems multshift is the tool!

12-08-2011, 03:21 PM
@ monovich
There's the "Normal Move" but only works to move all selected polys according to the first selected poly's normal.

Well Multishift has its limitations.

Here's a video about Shift: http://www.box.com/s/5i3ym8kr3pf82cpkas2a

I also have similar problems with Insets. I don't know the math under the hood, or the concepts, but It would be nice if Multishift could behave like the end result in the video.

Basicly on some situations, especially on skewed and trapzoid polygons Multishift doesn't work like one would expect, it's quite unpredictable.

I could go into more depth on the Inset.

The attachment object is like the video.


12-08-2011, 04:46 PM
Well I think clearly you have stumped the chumps here with this one.

Also I think it is a reasonable comment to make that every tool has its place. And clearly Multishift was not designed to give perfect angled results like you are looking for in that example.

Would be a nice feature though.

12-08-2011, 06:05 PM
For the circular loops you could use the right mouse button with (Modify>Translate>More) Move Plus (Bizzarely listed as Translate in the shortcut menu should you want to assign a key), though it's not much good if you need to be precise through utilizing the numeric panel. Move Plus + RMB works fine on circular loops ......... Perhaps I'm missing something. :question:

What he said: Move Plus +RMB works fine for the circular hole case.

::clik clik clik:: Yup, works for multiple discontinuous sections too. For the 'hole case', not the L-shape.

Last time I added this to my UI I renamed the button "RMB Normal Move" to remind me what it does. Trying to rememmber the difference between "Move PLUS" and "Translate PLUS" is a mug's game.

12-08-2011, 06:51 PM

You are right each tool as its place and Multishift doesn't cope with these situations or any other tool in LW does. And I don't think that it's a problem in LW alone, seems to me more of a problem of refined logic.

If I had made the whole loop and not just those 2polygons it would probably be even more confusing. And everything becomes a case by case. Which can be very time consuming. And it's specially frustrating when in your head it's clear what you want but you just don't see it through.


12-08-2011, 07:26 PM
What tools do other packages use to accomplish this task?

"Plagiarism is the sincerest form of flattery."


12-08-2011, 11:54 PM
If you have Softimage right now, any version before the 2012 advantage pack which just came out this year, you don't have a tool that does this. The very interesting thing about Softimage however is they waited to update the modeler tools until after ICE modeling was written.

Now the normal scale tool they introduced this year is written with ICE nodes, which means, anyone with an understanding of the ICE modeling workflow could have done it. And it also means that they have now ported the power of writing your own modeling tools over to the nodes system. Pretty damn cool. While designing ICE modeling tools may not be for the faint of heart, it is nothing at all like learning program language. It opens it up to far more users than any SDK could do.

And furthermore when you consider that all of these tools - even the normal Softimage modeling tools - can be animated. Pretty damn powerful!

As for Maya I don't have a definitive answer. But there was a video a guy released some time ago claiming that the Bevel tool in Maya failed even on the simplest tasks in regards to shifting evenly.

I also watched a fairly lengthy Maya tutorial recently where the guy was using the bevel tool a lot. He was constantly simply using the bevel tool and then switching over to the scale tool and scaling in X Y or Z separately to get his result.

I don't remember how well the Modo offering works.

So I think probiner is on the money. It is not just a LightWave-centric problem.

Blender is still waiting for Bmesh to finish just to have the Knife tool back and working again and still sadly, no bevel/shift tool. So all you have is the extrude tool and the scale or move tool in combination. They also have a smooth scale tool which works OK in some situations. But they make up for this loss in other ways with a fantastic workflow that trumps Modo's Workplane in my opinion. But is not as flexible as Softimage.

So in the end you wind up always in every program you use having to trade off between being able to have a tool that does exactly what you want and then having tools that don't and you have to simply find work arounds.

So there are two points to any discussion on this.

1) is development

2) artist not the tool.

They should be kept separate as subjects in my opinion.

Developments job is to listen to artist's needs and write tools to assist them.

An artist's job is to take what tools he has and makes them work regardless.

An artist fails any time he leans too heavily on development which is slow - in other words thinks he can not function unless tools are just so. So he complains and points the finger to the tool as the reason he can not get his job done.

Development fails when it does not listen to the legitimate requests of artists - even when asked for over and over and over again - and does not deliver tools that are needed.

And to me discussions fail when people talk about development needs and they get the "artist not the tool" response which only serves to take away focus from key development issues and puts the "blame" you could say back on the artist. This is not how development is fostered.

And also discussions about the use of tools fail when people crash the party and point the finger to development. This does not help an artist learn to adapt to what exists.

Development in LightWave molder has been a major fail for way too many years.

To LightWave modeler's credit. Still some of the tools available are much more powerful than in other packages. And Multishift is definitely one of them. I have never seen a tool in any other program that I have looked into with as much control over shifting. Modo - having come from LightWave development in the first place - is probably the only exception.

If the purpose of this thread was to learn the best way to do this, then I think all of the tools have been highlighted with all of the workarounds available.

If however we are talking development then probiner's example is a great feedback.

Just as examples of how the logic works for me. And a lot of times these threads go back and forth. If we were to try and keep our heads clear about which 2 subjects we are talking about at any given time, I think we can have much more productive discussions in my opinion. :)

12-09-2011, 01:58 AM
We are talking always about development and always about the artist, you can't separate them much in these discussions.

Discussions like this are precisely to make clear. They are both developments. The artist development as an efficient user of what there is, along side with questioning the tool development about what could be better.
I get you that it might do some noise, but lets be honest, if both are well spoken it's totally normal that a tool/operation under scrutiny, swings both ways. "Oh I did not know that" and "Well this doesn't do it, period". But normally it gets to a point where you think you know most of it, so the balance shifts toward development.

Work-arounds are fine, they make you feel smart, until they add hours to what you want to do, so then you feel pretty stupid ;)

Now you let me curious about ICE based tools :)

As for the tool's "logic", yeah sometimes you just look at the problems and you think "If only there was the option that the tool was aware of that and that" "If one there was the possibility to give priority to A, B or C while it does it's thing" and so on.

Conclusion. To me both belong in the discussion as long they are clear and they server the purpose of a forum discussion: knowing more, getting feedback, while being respectful.


12-09-2011, 03:40 PM
Yep. You're on the money there. It is a fluid thing. In a thread like this all is well. And it does go back and forth and it is a process of learning the tools and then realizing you know them and then get to the point where you can then say it is something that qualifies for a feature request.

That is what makes the forum work when it is working. The sharing of ideas and getting certainty that pretty much you have exhausted all options and finally you know you have that particular tool licked - at least for now. :hey: Until you find a tip someplace....

The reason I brought those ideas up was because I feel not separating these things at times is when the forum starts to breakdown as a working model and becomes an arena where people attempt to use either side of this issue as a way to knock down constructive ideas on the other side.

That has not happened here. But it is how these discussions can break down.

If I come along and say this tool is not working the way it should and the reasons why and you come along and say, well that's ridiculous it is the artist not the tool. That does not help a constructive conversation about the tool's development. And reason is it is comparison of apples to oranges.

The reverse is true as well.

But it is usually fairly obvious when someone is making a feature request that stems from a weak understanding of the tools. And an argument here about the artist use and understanding of the tool is appropriate because that is the solution for that particular situation.

In most situations all is well. In extreme cases - and there have been many here on the forums - these discussions fail to be constructive in my opinion.:)

12-10-2011, 12:48 PM
But it is usually fairly obvious when someone is making a feature request that stems from a weak understanding of the tools.
One aspect of LWM tools that is often overlooked by both beginners and veterans are all the different Falloff options. Some of the falloff options make a "meh" tool into a "must-use-constantly" tool.

Switchers from Maya particularly are surprised when Falloff is pointed out to them. :hey:

That said, Falloff has its drawbacks: users cannot tell from the cursor shape if any kind of falloff and/or what type of falloff is engaged, and the Numeric Panel must be open to allow the user to switch types (which IMO is very slow). In particular, TMK it is not possible to create a button or series of buttons that would specify Falloff options: eg, create a "Move: Radial Falloff" or "Move: Polygon Falloff" buttons and assign hotkeys to them. (Perhaps an LScript could be crafted to do this.)

Anyway, these enhancements (cursor indicator for falloff, specific hotkeys for specific falloffs) would help users in their work, and, to the point of this thread, help artists understand their tools better.

12-10-2011, 06:34 PM
I think Jeric touched on something that we really need in modeler. a quick way to see what is going on with the tools, what we are modifying and how. Every tool should be interactive, numeric imput is so 1990s ;o)

And if possible borrow a page from LWCAD's book by adding those new elegant contextual controls for the tool right into the viewports instead of a clumsy separate pannel.

12-10-2011, 07:02 PM
I think Jeric touched on something that we really need in modeler. a quick way to see what is going on with the tools, what we are modifying and how. Every tool should be interactive, numeric imput is so 1990s ;o) :agree:
Well put ("1990's, I spit on you!"). Heck, I've been carrying the flag for non-modality for DECADES. Literal decades, not figurative.

The interactivity you mention should be understood to include Preview options (the light blue line thingy) and selection status included falloff effect. Blender, for one, does that.

Frankly, though, I'd happily settle for the preview. (Like I have a choice. :bday: )