Notifications
Clear all

[Closed] script idea: Loop selection controlled by mouse movement

Hey all, I have been thinking of a selection improvement lately:

What about a script that shrinks and grows the selection on a loop (or a ring) by moving the mouse up or down. So basically, when you move the mouse up, it starts to expand the loop selection in one direction, while if you move the mouse downwards, the loop expand the other way, something similar to the video below, but controlled by mouse movement:

http://www.vimeo.com/8030056

Also something that would complement it very nicely would be the ability to select a certain ‘rhythm’ of edges along a loop – like the dotLoop in polyboost.

8 Replies

long story made short , I don’t think its possible

its actually possible but it will not improve the workflow at all
a tool like that has to be triggered somehow , you can’t use the mouseButtons to do that
and you will have to rely on a keyboard , why not push the grow or shrink shortcuts instead of triggering the tool and then move the mouse ?

another thing to consider , you have to tell the tool to stop growing or shrinking the selection , see why i say it will not improve the workflow ?

what about a keydonw that triggers the tool and when you finish your selection you release the key? AFAIK this is not possible through maxscript

I’m not into maxscript, but why not first you fire up the script with a key (say , the letter L, for loop), then you move the mouse up or down to define your selection and when you’re happy, you just press a left or right mouse button. Is this possible ?

I’m using a script to control the soft selection falloff with the same behavior as I described and it is very handy.

OK , here is a prototype
take care with your mouse movement , its very sensitive
I’ll test this for sometime … if i found it handy … i may expand and customize it , right now i’m not sure … i’m a shortcut guy and i still find my shortcuts faster !


macroScript selectBymouse
category:" CGtalk "
(
tool mouseLoops 
(
	local oldpos = mouse.screenpos
	
	fn getDirection = 
	(
		newPos = mouse.screenpos
		if abs(ewPos[2]) > abs(oldpos[2])  then 		
			(
				
				$.setLoopShift -1 false true
				oldpos = newpos
			) 
		else 
			(
				$.setLoopShift 1 false true
				oldpos = newpos
				)
	)
	
	on freemove do (if Selection != undefined and classof selection[1] == Editable_Poly and subobjectlevel == 2 do getDirection())
		
	)
starttool mouseLoops
	
)


evaluate the code and you’ll find a new category called CGtalk and assign a key to “selectByMouse” …
RMB to exit

I get this error when I try to run the script , what I’m doing wrong ?

Ok, my idea is to have 1 smart tool with behavior like this:

1)selecting one edge only and then running the script will allow you to grow/shrink the loop(or ring) via mouse movement. RMB to exit the tool when you are done.

2)selecting two edges right next to each other and then running the script will select the whole loop or ring.

3)selecting two edges with gap between them and then running the script will grow/shrink the loop with this pattern( dotted loop)

4)select limited edge loop by selecting two edges at the ends of the desired selection you want to made, then selecting a third edge somewhere between them and then. running the script

The idea is to combine this 4 tools into one smart tool (context sensitive to the selection).
What do you think about it, is it possible ? The concept is borrowed from MODO where you have one tool doing many things

the error you have arise from a missing letter at line 11

it’s not ew.pos[2] … it should be newpos[2]
so instead of

if abs(ewPos[2]) > abs(oldpos[2]) then

it should be

if abs(newPos[2]) > abs(oldpos[2]) then

i copied the whole code and it seems the forum dropped the n letter !

  • yes it’s possible to combine different functionality to the tool and right now its nothing but a first take , that’s not what i’m concerned about … the workflow what worries me … some tools may look great at testing but while you’re working on a real project , they seem very inefficient
    -this code is meant to make you test the behavior of the tool first , if its fine … we can polish it
    and add the desired functionality , again the tool is very sensitive to mouse movements … in my tests i added some threshold “not shown in the above code” but i’m still not satisfied about the “feel” of it

try this prototype first , and tell me what you think

Cyfer, Hi, thank you for the quick response, I’ve just tried out the script – It is running excellent this time (except that is too much sensitive!), but it is working not exactly how I was imagine it. Right now it is selecting in both directions and it only grows but doesn’t shrink the loop.It is not what i was talking about, sorry for my English , I can’t explain it better , so I did a simple animation to show you the desired behavior :

From usability stand point of view, I think it can be really useful. Right now I’m expanding a loop with the ‘+’ key (binded to “grow loop” which grows in both directions) and ‘-’ key for the shrink and whenever I want to grow only in one direction I need to go to the arrow keys next to the “Loop” button in the command panel. I also use LimitedEdgeLoop and LimitedRing scripts (both are part of csPolyTools). And sometimes(not so often) I use Polyboost’s DotLoop. Now imagine combining all this separate scripts to one smart script. It would be grate, right? You can bind it to a key and forget about searching thought menus or using 4 different shortcuts, or whatever.

Could you make it work like the animation above, please. Also it would be better if you can make it a bit less sensitive regarding the mouse movement, because right now it is pretty insane.

Cheers!

let me be very clear
-i’m not being lazy or something its just i don’t think we can get a modo behavior tool here
-i’m still not satisfied with the tool feel , adding functionality or polishing the code and adding features in this stage is a waste of time if you ask me .

here are 2 the main problems
1-threshold
now you think the tool is extremely sensitive , in my tests … i needed more sensitivity !
if you try it on a very dense mesh you will get my point .

2-abnormal behavior !

i have no explanation for that , if you move the mouse slowly you get the desired selection in your last post , go fast and things just get nuts !

this example provides a dist threshold — you can change that to your likings
and i tried to overcome the missed selection when moving fast with your mouse but … i couldn’t !
again move slowly and you will get the desired selection


macroScript selectBymouse
category:" CGtalk "
(
selectedEdges = polyop.getedgeselection $ 
tool mouseLoops 
(
	local oldpos = mouse.screenpos
	local refPoint = mouse.screenpos
	local dist = 2
	

fn getDirection dist = 
	(
		
		newPos = mouse.screenpos
		
		if newpos[2] < refPoint[2] and newpos[2] < oldpos[2] and (abs(newpos[2] - abs(oldpos[2])) >= dist ) do $.setLoopShift -1 false true 
		if newpos[2] < refPoint[2] and newpos[2] > oldpos[2] and (abs(newpos[2] - abs(oldpos[2])) >= dist ) do $.setLoopShift 1 false false 
		if newpos[2] > refPoint[2] and newpos[2] > oldpos[2] and (abs(newpos[2] - abs(oldpos[2])) >= dist ) do $.setLoopShift 1 false true
		if newpos[2] > refPoint[2] and newpos[2] < oldpos[2] and (abs(newpos[2] - abs(oldpos[2])) >= dist ) do $.setLoopShift -1 false false
		if newpos[2] > refPoint[2]  and  (abs(newpos[2] - abs(refPoint[2])) < dist ) do polyop.setedgeselection $ selectedEdges
		if newpos[2] < refPoint[2]  and  (abs(abs(refPoint[2]) - newpos[2]) < dist ) do polyop.setedgeselection $ selectedEdges
		oldpos = newpos
		
			--redrawviews()
	)
	
	on freemove do (if Selection != undefined and classof selection[1] == Editable_Poly and subobjectlevel == 2 do getDirection dist)
		
	)
starttool mouseLoops
	
)



I’ve just test it out and got your point. It’s just not feeling right. Hmmm

About the threshold, I’ve tried it out on several different meshes, a simple and a dens one(also tried different object scales because I was not sure if it has something to do with the abnormal behavior) – In theory, the sensitivity behavior could be polished by entering values for different average densities (lets say if it feels right on a loop consisting of 50 edges, in order to feel right with longer loops – the sensitivity should be multiplied, and so on). But yes, I got your point about sounding nice, and actually being usefull.
Another bug is that sometimes it starts to grow the loop in the wrong directon( Drag the mouse up – expands the loop down) and it has no logic why. Right now I like the fact that you can rotate the camera around the object without canceling the tool, also like that you can grow the loop with several steps (grow a bit, RMB to exit, then re-enter the tool and grow a bit more, and so on).

I still think that if we can find ways to make this tool more predictive and get the feel of it just right – it will come in handy. The whole point of this tool was to select quickly portions of the loop, witch otherwise could be done simply by the selectLimited Edge Loop that I described earlier(witch sometimes work, sometimes doesn’t). What do you think ?