Inside Sabertooth
Learn how Sabertooth uses 3ds Max to create 3D interactive projects, including HBO Go’s Game of Thrones interactive experience
  • 1/3
You are here: Forum Home / Autodesk 3ds® Max® / MaxScript / Vector Math in Editable Poly, Vertex Coordinate Systems and... Ugh
  RSS 2.0 ATOM  

Vector Math in Editable Poly, Vertex Coordinate Systems and... Ugh
Rate this thread
 
60610
 
Permlink of this thread  
avatar
  • Location: Columbus, Ohio
  • Total Posts: 434
  • Joined: 01 March 2008 04:43 AM

Back in high school I skipped math class. A lot. Who ever uses math, right?

So here’s my dilemma. A certain exporter I’ve been working on for many months has hit a wall and every time I return to it, I simply cannot solve it. After a recent discussion in the Modeling board on Normals, it gave me some food for thought and I think I understand the problem… but I’m just missing something.

I have two meshes. They both always share the same number of vertices… one is a control mesh used for calculating the distances of vertices in the second mesh… which is a mesh the artist uses to sculpt geometry. I need this structure for a specific format of geometry used in the Source Game Engine.

So we have this setup:

controlObject=ControlPoly -- 6-sided Box with N faces (height/width segmentsconverted into an editable_poly
sculptedObject 
ArtistSculptedPoly -- copy of controlObject

At export time I’m iterating over all the vertices of the poly objects and calculating the offsets. Because each side of the mesh has to be represented in the exported code as a single, independent face, I have an array of vertices for each Side of the original Box (controlObject) which is stored in an array called verticeStore.

Then for each Side, I have a block like this:

for i in verticeStore do (
 
 
sculptedVertex polyop.getVert sculptedObject i
 originalPosition 
polyop.getVert controlObject i
 dist 
distance originalPosition sculptedVertex 
 
 
if dist == 0.0 then (
  
unitVector [0,0,1]
 
) else ( 
  
unitVector normalize (sculptedVertex originalPosition )
 )

)

I have found that the code is almost right. But there is obviously something I am missing. For the majority of the mesh, the numbers are correct. But in the vertices at the edges/corners of the Box… the values are very wrong; and the only thing I can think of is that the vertex coordinate system is different along the edges than inside the faces.

I think it has something to do with the local coordinate system of vectors sculptedVertex & originalPosition used in the lines:

unitVector normalize (sculptedVertex originalPosition )

I think I need to rotate the unitVector . Is there some kind of offest I have to add/subtract? How do I determine this value? Also, what is the tip-off that you’d need to do this (instead of storing an array of vertices that are along the edges)?

I am sure there is some simple solution. But like always… my lack of experience in MAXScript and sub-expert math skills combine to thwart me. I have tackled this problem for months and have to concede that I can’t solve it alone.

In the attached images, I am showing:

1) The two meshes in Max where the semi-transparent cube is the control mesh is controlObject (control mesh) and the sculpted mesh is sculptedObject.

2) Showing geometry exported to game IDE from around the same angle. Notice the black gap between the front and the side.

3) Showing the mesh from another angle… where the corner in yellow actually is correct but all others (circled in orange and red) are incorrect.



______________________________
Shawn Olson’s Creative Arts
Developer of the Wall Worm Model Tools for Source
And my Favorite Unsung Plugin: Convexity for Level Design

Max 4/Gmax, 2008 - 2013
Mudbox 2009-2011
Win 7 x64 (x4)
Geforce 480x2 | Geforce 275x1 | ATI Radeon HD 3200 | Intel Generic chip
8GB | 12GB | 4GB | 4GB
Intel Quad 6700 | i7 930 | Athlon QL-65 | Intel Quad 6700

Attachment Attachment
Attachment Attachment
Attachment Attachment
Replies: 0
avatar

As it turns out… there may be other problems that are causing this… and it looks like the normalized vector method above is fine. Other bad logic in my code is more likely the culprit now.

Ahh… the fun of not knowing EVERYTHING like I’d like… :)



______________________________
Shawn Olson’s Creative Arts
Developer of the Wall Worm Model Tools for Source
And my Favorite Unsung Plugin: Convexity for Level Design

Max 4/Gmax, 2008 - 2013
Mudbox 2009-2011
Win 7 x64 (x4)
Geforce 480x2 | Geforce 275x1 | ATI Radeon HD 3200 | Intel Generic chip
8GB | 12GB | 4GB | 4GB
Intel Quad 6700 | i7 930 | Athlon QL-65 | Intel Quad 6700

Replies: 0
avatar

OK… so I figured out the whole dilemma. As it turned out… all the unit vector stuff was fine all along.

The whole dilemma (that stumped me for many months) was that the ordering of vertices on faces works nothing like I had assumed. I had presumed a specific order (and held to that belief since the vertices very often were ordered such).

So the error came down to the wrong vertices along edges getting computed… which led to all the problems.

Thank God that one is behind me.



______________________________
Shawn Olson’s Creative Arts
Developer of the Wall Worm Model Tools for Source
And my Favorite Unsung Plugin: Convexity for Level Design

Max 4/Gmax, 2008 - 2013
Mudbox 2009-2011
Win 7 x64 (x4)
Geforce 480x2 | Geforce 275x1 | ATI Radeon HD 3200 | Intel Generic chip
8GB | 12GB | 4GB | 4GB
Intel Quad 6700 | i7 930 | Athlon QL-65 | Intel Quad 6700

Replies: 0