Page 1 of 1

Object Snap (transform)

Posted: Tue Oct 25, 2005 12:11 am
by wizzleteet
Hia,

If one were to code an object snap, where in the source tree would it belong?

Proposed basic use (to get things started):
1.move object based on a from-vertex-to-vertex vector.
2.move sub-object (face,edge,vertex) based on a from-vertex-to-vertex vector.
3.move (sub)object based on a from-{(mid,perp,end)-edge or cen face or vertex} to {(mid,perp,end)-edge or cen face or vertex}

UI considerations:
mouse-over lites up {(mid,perp,end)-edge or cen face or vertex}

Actually, without this, blender will never be considered a serious modelling tool. Without this basic functionality, one can never garantee a model to have internal integrity.

OK, so where would this go ?

wizzl

Posted: Tue Oct 25, 2005 12:26 am
by LetterRip
Hi,

look in blender/source/blender/src

the transform code (files with transform in the name) or meshtools code (with meshtools in the name) are your most likely bets for the function part of it.

the interface code - if you use keybindings check space.c

for buttons see buttons.c

once you code the basic function where it should go in the interface can be better decided.

You might want to talk to intrr (who has coded bounding box based snapping and other snapping stuff for his DTPBlender (desktop publishing blender fork)) not certain how applicable his code will be (and since he codes it for himself, it is sometimes not easily readable by others).

Theeth is the transform code maintainer, so could probably give you hints there.

Guitargeek is one of the meshtools maintainers so he might be able to offer some hints there.

LetterRip

Re: Object Snap (transform)

Posted: Tue Oct 25, 2005 2:24 am
by lukep
wizzleteet wrote:Hia,

If one were to code an object snap, where in the source tree would it belong?

Proposed basic use (to get things started):
1.move object based on a from-vertex-to-vertex vector.
2.move sub-object (face,edge,vertex) based on a from-vertex-to-vertex vector.
3.move (sub)object based on a from-{(mid,perp,end)-edge or cen face or vertex} to {(mid,perp,end)-edge or cen face or vertex}

UI considerations:
mouse-over lites up {(mid,perp,end)-edge or cen face or vertex}

Actually, without this, blender will never be considered a serious modelling tool. Without this basic functionality, one can never garantee a model to have internal integrity.

OK, so where would this go ?

wizzl
Hmm. snap features are considered in the 3D CAD industry as something of the past (well on all modern softwares, ie not autocad-inventor), inherited from 2D habbits.

the modern methods, which are constraints, are much more usefull, because they are more dynamic. Especially when you consider that a good part of what is needed already exist at object level and just need to be expanded both at this level, and in the mesh itself. adding purely geometric references (specialized empties) would help too.

and vertex parenting is a snap feature btw

for mouseover, the limit is that meshes have no topology info, and it is so very CPU intensive/

Posted: Tue Oct 25, 2005 11:10 am
by LetterRip
lukep - Ton just added an octree to editmesh.

Mouse over highlight is sort of a secondary issue to me, but what is interesting is the inferencing done in sketchup, which includes midpoint (and other useful points) highlighting. Also theeth has some experiments he is doing with the manipulator for parallel action to an axis inferencing.

So much of the same stuff needed for mouse over highlight is also needed for automatic inferencing of midpoint.

I'd be interested in seeing a vid on snapping and what it has as an improvement over constraints.

LetterRip

Posted: Tue Oct 25, 2005 11:17 am
by LetterRip
lukep - also I don't see why it would necessarily be overly processor intensive.

you can do it the way that the projection painting does

1) assign each face, edge, and vertex its own color (you can make edges and verts fat, and paint the faces, then edges then verts)
and have a map that has a pointer from the color index to the face/edge/vert

then at each mouse point, sample your buffer color at the mouse location and highlight that element.

That is one color sample and index lookup per mouse move which shouldn't take hardly any time at all

LetterRip

Posted: Tue Oct 25, 2005 10:57 pm
by wizzleteet
Hmm. snap features are considered in the 3D CAD industry as something of the past (well on all modern softwares, ie not autocad-inventor), inherited from 2D habbits.
Well then, if Blender does not have a snap capability,

just how much of the past is Blender in that case?


I mean, seriously, I am fluent in Pro-En as well as Max, Maya, Rhino (acad illustrator yadayada etc) and I feel very much that parametric software is of a higher order than the aformentioned animation-packages.

Nonetheless, the endresult one needs usually ends up being a mesh of some sort, and then, having a snap is tantamount for any program dealing with meshes.

Posted: Wed Oct 26, 2005 1:09 am
by LetterRip
wizzleteet,

have you looked at sketchup?

http://www.sketchup.com

have a look at their video tutorials particularly the inferencing tools

http://download.sketchup.com/downloads/ ... C_high.wmv

LetterRip

Posted: Wed Oct 26, 2005 9:54 pm
by lukep
strangely my yesterday answer did not reach the forum.
wizzleteet wrote:
Hmm. snap features are considered in the 3D CAD industry as something of the past (well on all modern softwares, ie not autocad-inventor), inherited from 2D habbits.
Well then, if Blender does not have a snap capability,

just how much of the past is Blender in that case?
vertex parenting is a kind of snap feature.

and blender has constraints at object level. what lacks is the same at vertex/edge/face level.

I mean, seriously, I am fluent in Pro-En as well as Max, Maya, Rhino (acad illustrator yadayada etc) and I feel very much that parametric software is of a higher order than the aformentioned animation-packages.

Nonetheless, the endresult one needs usually ends up being a mesh of some sort, and then, having a snap is tantamount for any program dealing with meshes.
different objectives means different methods. dont try to find in an artist tools, features needed for engeneering. i agree though that more controls is a good goal. but the trick is to do it the right way.

I'm too very fluent in serious CAD software (Solidworks, a bit of Catia) and i'm positive that constraints are more dynamic and useful than good old snap. solidworks use exclusively constraints and that a real advantage.

You can already do a lot in blender playing with empties and vertex or hook parenting + constraints. granted, this is not intuitive, but aligning objects between them is not a problem. Vertex parent an emptyy+ copy location => snap 2 objects.

What you cannot do is to build those same constraints in edit mode of one object (even if hooks solve partially this need)

Adding constraints in edit mode for mesh components (or groups of) will give you all the control you need, while keeping things dynamics. that mean you could even add an IPO for control in time. More, constraints can be blended, snaps cant.

Note that when speaking of vertex/edge/face constraints in edit mode, that dont means the object become deformable. Edit mode constraints should be restricted to the edited object (or things become too messy in terms of dependancies). Out of edit mode, situation is the same as before.

that's why i feel that snap features is not the way to go, when we have a better method possible, which would not cost much more work.

Posted: Thu Oct 27, 2005 12:34 pm
by uk_rookie
Hi,

It has been pretty interesting following this thread and it is obvious that you are all a lot more knowledgeable than me. But I have a couple of observations.

The Snap tool may or may not be outdated, but its real importance being a highly intuitive tool for new users. As a fairly new user, I think that intuitiveness is the only real issue that Blender has.

Having started out using Adobe products and then moving onto Solidworks, Alias, Rhino etc. I have found that it is the use of a common language, symbols and tool types has been essential for transfering from one to the other. Therefore I think that the kind of thing wizzleteet was suggesting would be an essential tool, even if better results can be achieved by less intuitive means.

Posted: Fri Nov 04, 2005 2:13 am
by ysvry
snap on midle of edge or on plane is a very handy option in sketchup and not outdated at all, blender would benefit alot if it had such functionality as its dificult to place verts exactly in 3d through a 2d screen.

Posted: Sun Nov 13, 2005 1:25 am
by dumbf
lukep

I don't believe object snap is a thing of the past. It's well a truly here to stay.

Why do you elevate solid modelling soft above 2D/3D cad like AutoCAD they are both very valid soft for different jobs but fundementaly the same.

3Dmax has object snaps.

Where do you think a great many new users come from who try Blender, from a 2D CAD environment with object snaps looking to combine their CAD skills with a intuitive (to them) 3D modeller and visualisation software.

I'm from a CAD background and Blender is a pain in the ass without Object Snaps. Not being able to pick a point on a mesh as quick as just thinking 'that point' 'snap' rotate, mirror, move, etc etc move mesh to that snap point 'bang' done no chasing the 3D cursor around ctrl s this and ctrl s that.

How many CAD types do you think just give up on Blender as antiquiated and backward because they can't manipulate objects meshes as quick as thinking.

Posted: Sun Nov 13, 2005 2:09 am
by Caronte
Object snap is NOT a thing of the past

¿Example?
Check the video of Silo:
http://www.nevercenter.com/tutorials/videos/

Posted: Sun Nov 13, 2005 5:35 am
by ZanQdo
Actually, without this, blender will never be considered a serious modelling tool. Without this basic functionality, one can never garantee a model to have internal integrity.
That´s your opinion.

Intrr have coded snaping in instinctive blender allready... But It´s difficult for a new feature like that to make it to BF