All feedback is appreciated and these two points seems to be most prevalent.
I want to work on ease of access first, that’s at least something that i can work on by myself.
But precision, if you have an issue with it please show me examples of where the current script is insufficiently exact. RickyBlender do you understand that the tolerance allows for less precise geometry but does not at the same time penalize higher accuracy if the user is working at high precision?
I am sure you have your idea where you are going and I’m not questionning that. I was just sharing the inspiration your script gave me.
About precision. Your script seems far enough precise for my needs(I’m an artist). In fact I was using the wrong word. I meant tolerance. sorry, I am totally ignorant in this domain. What I was saying is that in situation where edges does not intersect, a hypothetical point of view projection could give a coordinate cause the point of view is 2d. This may be useful for less precise works like art modeling. “edge slice at intersection”, and “extend towards edge intersection” are not very tolerant. They only works when edges are coplanar. “Edge extend projected intersection” is very tolerant compared to the others, but the result is sometimes unexpected.
exemple of Edge extend projected intersection
with absolutely non coplanar edges:
At least in a point of view projection, the result would be what the user could expect for it is based on what he sees.
But as I said, I know nothing of all that. I hope this makes sense.
Wacky results on that picture, cool, I have been looking around (not intensely…yet) for a way to check edges for being coplanar regardless of rotation. While it might seem that i limit the user to be more accurate, my intention behind the script is for relatively accurate geometry anyway. Unexpected results are a sign of careless programming, clearly more effort needs to be put into dealing with scenarios that wont provide useful results. Thanks for that input. A UI slider for tolerance might be a fun project for someone else to include.
I consider myself foremost artistic and this python stuff rises more from a frustration around lack of 2.55 geometry tools. The snap to edge/vert stuff seems to me sufficient for eyeballing/art geometry.
Now, there might be a reason to code a quick offset script that uses the viewport/rotation and a selected edge followed by a mouse click in the direction of the desired offset, followed by entry of offset value (either manual, or selecting an edge for it’s length as a distance). because things like that i do miss from autocad particularly.
updated into one script. renamed the specials menu functions to (as suggested)
Edges V intersection
Edges T intersection
Edges X intersection
go to the first post for a download link : http://blenderartists.org/forum/showthread.php?t=204836
It could guess what context is required and reduce the menu options, but i have other ideas (ie, T intersection mode to allow as many edge selection as desired for a mass weld/slice).
ok one suggestion or option
first for the debugging phase might be easier to ahve it in the operator panel then when fully debugged you can make it as an addons or added to Mesh menu or other W key!
i would suggest to add the options in the operators panel wold be faster to get options then to search in list for W key
but this is a choice you can decide !
nice going
but when i was talking abou precision / tolerance
being limtied to 7 digits is in terms of CAD quit limited !
and i’ have seen thread on this subject of people trying to do things with blender and they where very frustrated
with Face not being really co planar at high resolution!
if you can find the little algo to test for Co planar faces of vertices it hink it would be nice to check it !
note i updated to ver 760 hope your are following in case of API changes again!
happy 2.5
I disagree, now if i can add a hotkey to the specials menu for V, T , X all a user will need to do is
Where, point me to one.
please refer to the full blender revision ( ie 33760 ) dropping the 33 will only lead to confusion and doesn’t gain you any real time-benefits.
I suppose anyone doing a building is modeling in metric system.
Now, 1 unit in blender would be then 1 meter (this seems be now the standard).
A number like: 0.001 would be 1 milimeter and we are with 3 digits for floating point.
with six digits we would be talking about dividing 1 milimeter in 1000 parts. I can’t believe someone is doing that in architecture.
By the way try yourself to create a cube of 1mm. Now duplicate and build another of 0.1mm and you need go to orthogonal view to view it because cam is not showing it (you would need to change the planes clipping etc). But even in orthogonal there is a limite you can zoom. That means that Blender only let you model in tenths of milimeter? No, you can, if you really need to model so little, change the scale (just below of metric system button). If you have a blender cube of 1meter, changing the scale to 0.1 would convert the cube to 10meters. Then you can go and model in nanometers if you want with the scale.
Really, if any architect is using tenths of milimeters modeling a building he needs take some holidays.
Perhaps for mechanical pieces design, it be needed four digits or five in some cases of very little pieces. But I just want an example where you need seven digits. That is 10 thousand part of 1 milimeter in scale 1 blender unit = 1 meter!
In the case you need four digits from a meter set the scale to 0.01 for example
it’s one aspect of the problem
in architecture usually here we use millimeters for whatever lenghts are shown on DWG like 2245 mm
but i was talking more about mechanical parts which can have high precision < 0.001
but your right you can change the scale to get lower then 0.001
that’s not where the problem is here it’s the fact that quad faces in blender are not always co planar
but you may see this in viewport but for some mechanical design/modelling and for CAD equivalent this is not good enough!
also when you are doing long calculations using only 7 digits you get cumulative errors which are significatives
and not nill
i will try to find some threads on this subject but in 2.49 this was discussed a lot a long time ago over 1 1/2 year
but in any case keep going with your script for the time being it’s working well and if other peoples complaints
then fine they can always use a real CAD system!
happy 2.5
I would like to see a blend file with these problems (the non coplanar polygons thing), to see if there is a solution. But at the moment I can’t see any problem (if you use the Scale thing as said).
I didn’t looked yet at the structure of the blend file but I suppose if they change float numbers to double numbers there would be an impact in performance. But the solution would be using doubles in all in blender instead floats and only use floats or even lower in renderer. To change from floats to doubles could break a lot of code if it was not designed to be able to do this in the future (I am sure it is this way and would break many code and so a nightmare to fix). It is this way: Imagine you use floats in the code and you know that them are four byte long. For moving a vector you just use an optimized function that moves 12 bytes (three components,xyz and 4 bytes for each). That is faster because you are just moving a block of memory with hyperfast assembler commands. But you can’t change tomorrow xyz to store doubles (8 bytes) because you find this copy doesn’t works anymore. The “correct” way to do it (but slower) would be to check the type of xyz, calculate the length, store a variable indicating the lenght of the type and then the values. As you see that is slow, but it would be “portable” to easy changes. But people would say: holy shit why blender is soooo sloooow? Compare with this or that zbrush!
But I think that making doubles instead floats all except at rendertime is a thing to have in the TO DO list in a future.
In computers numbers are stored in a “strange” way called floating point that converts any number to format 0.xxx * 10**y (y is pow(y)) (for example 100 would be 0.1 x 103) and there is not a exact way of representing numbers this way. For example 0.707 never would be stored and retrieved as 0.707 anymore but something like 0.706999997423…). That is the problem with floats and doubles.
Bankers said that was intolerable and the solution was to create the Decimal variables. Decimal stores a representation of the numbers just like they were just a string of characters. Then they are operated as we did in our young scholar time: for example to multiply 43 x 23 you do 43 x 2 and the result is added a 0 to the end and then 43 x 3 is calculated and the result added to the former one. This is done without conversion to floats or doubles. So it is slow. I wonder if someday someone implements such a system just to know how slow would be blender with that.
but have you ever seen this thing about quad that are not co planar before in blender and other soft i think too?
i know may peoples think that quad are co planar like flat plane but in blender it’s never been the case
but most of the time it does not bother anybody for rendering
except if you really need high precision like you do on a CAD then it may become a problem!
we could talk about this subject for a long time and it’s already been discussed in other thread so don’t want to start a war of words here
so just keep it in mind
you already know that there is a difference of precision between blender and CAD system !
happy 2.5
No, that is correct. Quads are just two triangles. That is not an error, it is as it is coded. In 3dsmax is the same way. Then you have in this “non coplanar” quad a edge that in max can be changed and in Blender can’t. I plan to resolve this because changing this edge from mountain to valley shape or viceversa can create better subsurfed result. At the moment I separate the quad, rotate it 90 degrees and join to the mesh and weld again. A lot of steps that a script can do quicker.
many newbies think that a quad is really a co planar surface or rectangle and it’s not
it’s more like 2 tris but ususally this is not a problem unless you are using the data’s in a script and work at the limit of precision of the 7 digits then it can accumulate lot’s of little errors when doing several math operations in sequence !
anyway waiting for the next version of your script
thanks and happy 2.5
I posted a Final Version that works at last in 3DView in the Cursor Control thread. Now I want to port that to work with vertices in the Edge Tools script on this thread, that seems the perfect place for it. Always with zeffii permission of course.
it will take me a little while to settle on an efficient coplanar check,
something like from the two edges, take verts v1, v2, v3, v4
normal_one = mathutils.geometry.TriangleNormal(v1, v2, v3)
normal_two = mathutils.geometry.TriangleNormal(v2, v3, v4)
isWithinTolerance(normal_one, normal_two) will be interesting.
yes, by all means you are welcome to use it. and if you have improvements please feed them back 
for search:
co planar check for two edges,
co planar check for 4 points, 4 vertices
i’m offering this up for scrutiny, i’m no math whiz. This seems ok for my needs, but testing has not yet been exhaustive.
import bpy
from mathutils import Vector, geometry
def getMeshMatrix(obj):
is_editmode = (obj.mode == 'EDIT')
if is_editmode:
bpy.ops.object.mode_set(mode='OBJECT')
edges = []
mesh = obj.data
verts = mesh.vertices
for e in mesh.edges:
if e.select:
edges.append(e)
meshMatrix = []
edgenum = 0
for edge_to_test in edges:
p1 = verts[edge_to_test.vertices[0]].co
p2 = verts[edge_to_test.vertices[1]].co
meshMatrix.append([Vector(p1),Vector(p2)])
edgenum += 1
return meshMatrix
def checkIsMatrixCoplanar(verti):
def isWithinTolerance(n1, n2):
tolerance = 1.0e-6 # 1.0e-7 seems too strict occasionally
difference = (n2-n1).length
if difference < tolerance: return True
else:
print(str(difference) + " is going to produce unexpected behaviour, ending operation")
return False
v1 = Vector((verti[0][0]))
v2 = Vector((verti[0][1]))
v3 = Vector((verti[1][0]))
v4 = Vector((verti[1][1]))
normal_one = geometry.TriangleNormal(v1, v2, v3)
normal_two = geometry.TriangleNormal(v1, v2, v4)
if isWithinTolerance(normal_one, normal_two):
return True
else: return False
obj = bpy.context.active_object
verti = getMeshMatrix(obj)
if checkIsMatrixCoplanar(verti):
print("seems within tolerance, proceed")
else:
print("check your geometry, or decrease tolerance value")
# return {'FINISHED'} #shouldn't do anything
Both are the same problem. In 1) you take two points on each edge and then jump to 2) problem.
A plane is defined by three vertices. A fourth vertice is at a distance from that plane if it is not on that plane (co-planar: in the same plane). I have seen (mathutils.geometry perhaps?) a function about intersection of a ray with a triangle. We have a triangle and a vertex. if we calculate the normal of the triangle plane we can have a ray (that normal and the vertex we want to know if is coplanar with the triangle). With that ray and the triangle function we calculate a vertex where the ray touches the plane. This vertex on the plane and the one floating you calculate the distance and see if it is near 0 then are coplanar.
Explain your method because I was reading yesterday and I think is flawed but I am not sure until you explain better (no time now to understand your code)
This script works with the geometry that blender provides and as a result is going to be as accurate as the geometry engine of blender. I will continue to keep the print-statements so the attentive user can see the kind of margins being produced by the various math procedures.
The reason i increase the tolerance is because i’ve noticed that sometimes it was too strict. The remove doubles lateron is probably the biggest precision reducer, but that can be adjusted i guess…
Anyway, i did some updates.
i know both are the same
I’m picking one edge and making a tri with a vert from the other edge. then calculate the normal of the face
then i make a tri with the other vert, and check if both normals are the same. if not , then the whole setup isnt coplanar.