At the moment if I want to get all 8 vertices of a box I have to convert it to mesh first and then use meshop functions. I think converting to poly and using polyops function would give the same result, but i don´t want to convert the box. Is there any way to get the vertices without converting the box?
You can try using the box geometry .mesh property. i.g:
for v in $.mesh.vertices do print v.posThanks a lot. Wondering why the maxscript documentation never mentions that .mesh property.
Is the order of .mesh.vertices always the same? I mean .mesh.vertices[1] is min and .mesh.vertices[8] is max.
Documentation is a bit lacking imo, I couldn’t find .mesh property there either.
I don’t think box vertices are always ordered the same way… if what you are looking for is the max a min positions there are .max and .min properties for this. $.min, $.max…
I know, but at least $.max returns not 100% corect value, example real max is (1, 1, 1) but $.max returns something like this: (1.0, 1.0, 1.000001).
You’re aware of the inherent imprecisions of floats (single-precision ones here), right?
Yes I am, but why it´s only Z-axis having problems with precision?
When the point or object is transformed, it’s a lottery which point will get slightly different value. It’s not like it’s a general case as you present it.
b = box width:1 length:1 height:1 widthSegs:1 lengthSegs:1 heightSegs:1 pos:[.5,.5,0]
for i = 1 to 3 do format "%\n" (formattedPrint b.max[i] format:"#.16g")
--> 1.000000000000000
--> 1.000000000000000
--> 1.000000000000000I really wouldn´t call it lottery because if lottery would worck this way, I´ll be very rich. It´s not a random precision problem, in my case, I have used max at least 20 times, not only with boxes, but other meshes and everytime only the z-axis was wrong. With min there were never such precision problem. As you posibly already know, I am using older 3ds max versions, so this could be some old bug, that was posibly fixed in new versions.