Mesh/Cas/Engine - MaxScript version of GOAT tool

[johnwhile]

uhm... very interesting test, is possible that my script don't compute the true Binormal and Tangent vector. The test that i made is based for Building version, the Mesh/Cas/engine script utilize the same function:
In the geometry_class.ms script there are the function:

Spoiler Alert, click show to read: 

for f=1 to numfaces do
(
--FACES
Faces[f]+= [preVert,preVert,preVert]

local fnormal = normalize (getFaceNormal tmesh f)
local i = Faces[f].x
local j = Faces[f].y
local k = Faces[f].z

local v1 = verts[i]
local v2 = verts[j]
local v3 = verts[k]

local uv1 = tvert[i]
local uv2 = tvert[j]
local uv3 = tvert[k]

local dV1 = v2 - v1 --[x1,y1,z1]
local dV2 = v3 - v1 --[x2,y2,z2]

local dUV1 = uv2 - uv1 --[s1,t1]
local dUV2 = uv3 - uv1 --[s2,t2]

/* area is the Length(cross dUV1 dUV2) but max want point3 */
local sign = if (dUV1.x * dUV2.y - dUV1.y * dUV2.x) < 0 then -1 else 1 -- r = 1.0 / (s1 * t2 - s2 * t1);
local r = 1.0 / (dUV1.x * dUV2.y - dUV1.y * dUV2.x)

local tangent = [0,0,1]
tangent.x = ( dUV2.y * dV1.x - dUV1.y * dV2.x)*r -- (t2 * x1 - t1 * x2) * r
tangent.y = ( dUV2.y * dV1.y - dUV1.y * dV2.y)*r -- (t2 * y1 - t1 * y2) * r
tangent.z = ( dUV2.y * dV1.z - dUV1.y * dV2.z)*r -- (t2 * z1 - t1 * z2) * r

local binormal = [0,1,0]
binormal.x = ( dUV1.x * dV2.x - dUV2.x * dV1.x)*r -- (s1 * x2 - s2 * x1) * r
binormal.y = ( dUV1.x * dV2.y - dUV2.x * dV1.y)*r -- (s1 * y2 - s2 * y1) * r
binormal.z = ( dUV1.x * dV2.z - dUV2.x * dV1.z)*r -- (s1 * z2 - s2 * z1) * r

--local binormal = (cross normal tangent) * sign
/*
r = 1.0 / (s1 * t2 - s2 * t1);
sdir = new Vector3((t2 * x1 - t1 * x2) * r, (t2 * y1 - t1 * y2) * r, (t2 * z1 - t1 * z2) * r);
tdir = new Vector3((s1 * x2 - s2 * x1) * r, (s1 * y2 - s2 * y1) * r, (s1 * z2 - s2 * z1) * r);

tan1[i1] += sdir;
tan1[i2] += sdir;
tan1[i3] += sdir;

tan2[i1] += tdir;
tan2[i2] += tdir;
tan2[i3] += tdir;
*/

tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent

bitang[i]+= binormal
bitang[j]+= binormal
bitang[k]+= binormal

-- check if max return a wrong orientation, else flip face
if dot fnormal (cross dV1 dV2) < 0 then swap Faces[f].x Faces[f].z
--if flip do normal = -normal
)

The Normal Vector can't be differenct, the Binormal is the cross product of norm and tang so can't be different, try to change the sign of tangent
tang[i]+= tangent * (-1)
tang[j]+= tangent * (-1)
tang[k]+= tangent * (-1)
In fact, about these calculation i had a lot of issue (shadow, ecc...) in the building, i think i must change some value


About "Per vertex TBN" matrix, see also:
http://www.gamedev.net/topic/464820-...x-curiosities/
http://jerome.jouvie.free.fr/shaders/Shaders.php

[kompadre]

I have 1 idea about that.

As I know, old mesh2ms3d_beta18 shifts UV when converting - because when you convert back, almost all UV shifted to u = 1 (or -1 i dont remember).
May be that is reason (U = U - 1 --- and U became negative) ?

[johnwhile]

No, the uvw conversion is correct, if I invert u or v, you see wrong texture in game, mesh2ms3d_beta18 or other scripts are indifferent. Ops , one moment.... I forgot to re-scale the u coordinate for standard unit after the formula of tangent and normal

[kompadre]

... Ops , one moment.... I forgot to re-scale the u coordinate for standard unit after the formula of tangent and normal

Is this bug corrected in release 40 (Or may its not a bug at all) ?
By the way unpacked
- r40 ~= 3.7 mb
- r39.1 ~=5.4 mb
This is very strange .

tang[i]+= tangent * (-1)
tang[j]+= tangent * (-1)
tang[k]+= tangent * (-1)

I still need to try that in r.40 (I didn't try in r39.1 because you said

... I forgot to re-scale the u coordinate for standard unit after the formula of tangent and normal

) ?

[johnwhile]

don't worry about dimension, is possible that i deleted some unused file, or write the m2tw_3dstudio_scripts.chm, i usually use this syntax rXX.y = release XX bugfix y.

Ok now i re-scale the U coordinate after compute tangent (the difference between KE's tool that i don't use two material but i scaled the U coordinate to 0.0 - 2.0 to work correctly with two texture.), but there aren't visible difference in game because i see the formula and the result vector is always normalized. In the script you can find the file "@geometry_class.ms" with inverse tangent, switch the file lib/geometry_class.ms and see the difference, close and restart 3dstudio to reload the script.
I think this is the only solution, the normal vector can't be different otherwise you will se flipped faces

I find these formulas in internet but i had a lot of problem testing in game , especially with building shadows... so i think this is the definitive formula

You can also invert the Binormal and Tangent vectors here:

Spoiler Alert, click show to read: 

for i=1 to numVertex do
        (
            local v = verts[i]
            local n = normalize norm[i]
            local t = normalize tang[i]
            local b = normalize bitang[i]
            
            --ortogonalizzazione di Gram-Schmidt di primo ordine
            t = normalize ( t - n*(Dot n t))
            --ortogonalizzazione di Gram-Schmidt di secondo ordine
            --if det!=0 then b =normalize ( b - n*(Dot n b) - t*(Dot t b)) else b = cross n t
            b = normalize (cross n t)-- il vettore Binormal è sempre ortogonale =  NxT

            tang[i] = -t
            bitang[i] = -b
            norm[i] = n
        )

but, as you see, i put some formulas as comment because i used the "Try And Error" ways XD, i tried some calculation with and without some code and i saw the result in game.

[VINC.XXIII]

Hello Johnwhile(the Master Engineer), I would know, by chance, do it would be easy to change the ribaudequin's spears and to put instead some voulge/halberds?
I don't want especially great effects of defense regarding these new wepons.

Just to change the vanilla harpoons if its not so "technic"

Spoiler Alert, click show to read: 

[johnwhile]

the "master engineer" don't understand the question: you mean the ribaudequin's model or ribaudequin's projectiles ?

For model is sufficient import the ribaudequin.mesh with my script (i suggest to use Only Assignements if you don't work with animation), the problem of GOAT is that can't work with different skeleton, but i know that KE's add some vanilla engine skeletons.

For projectiles is a little complicated, you must find with descr_projectile.txt missile's cas reference but:
the game uses two ways to represent the bullets

1. missile model : .cas extension
2. particles system : like fire, smoke ecc... use some square with a tga image

but I don't have much depth about it, example for Catapult bullets i found missile cas's model just by random.

To change the projectile system, effect, damage ecc.. you must use only the text files, because all these information aren't relation with 3d models (mesh and cas files)

[kompadre]

R40.1 BugReport....

See the attached pic.

p.s. I used normal version tool without switch @geometry_class.ms. In fact i did nothing but used the r40.1 at defaults

[VINC.XXIII]

No just the model, I don't want that thrown halberds and voulges...

"For model is sufficient import the ribaudequin.mesh with my script (i suggest to use Only Assignements if you don't work with animation), the problem of GOAT is that can't work with different skeleton, but i know that KE's add some vanilla engine skeletons."

Thanks you, +rep

[johnwhile]

R40.1 BugReport....
See the attached pic.

Sorry, i put [1,1] and not [1,1,1] without testing ...

No just the model, I don't want that thrown halberds and voulges...

I see Milkshape, are you using GOAT for this ? Attention, is possible that GOAT convert it with human skeleton, try to reimport in milkshape and look the skeleton.

[VINC.XXIII]

Its true("GOAT convert it with human skeleton") , I will restart from this info, I have merged the weapons and the machine with Goat.
Thanks

[kompadre]

johnwhile

Ok now i re-scale the U coordinate after compute tangent (the difference between KE's tool that i don't use two material but i scaled the U coordinate to 0.0 - 2.0 to work correctly with two texture.), but there aren't visible difference in game

Yeah.. I can't see any difference too.

tang[i]+= tangent * (-1)
tang[j]+= tangent * (-1)
tang[k]+= tangent * (-1)

This working! But not as we wanted to... But working.

This expressions gives ability to correct use normal-textures which made with options
{ Invert X ( Flip Green (x) - for Max) }
(Of course, if normal-texture was made with another options, for example {Invert X ; Invert Y}, in this case the tools used it wrongly)

I remind you, that usual expressions in the tools (without minuses) gives ability to correct use normal-textures which made with options
{ Invert Y ( Flip Red (y) - for Max) }

And mesh2ms3d_beta18(created by grumpyoldman if i remember his nickname right) - gives ability to correct use normal-textures which made with options
{Invert X ( Flip Green (x) - for Max) ; Invert Y ( Flip Red (y) - for Max)}

And it seems to be that we have a problem here ...

Many-many units was converted (earlier, before Mesh/Cas/Engine was made) by mesh2ms3d_beta18... And that units, of course, used normal-texture with {Invert X ; Invert Y } options.
Now: what if I want to slightly tweak some old unit with your great tool? - No problems. I convert unit in to Max, then tweak, then convert back in to game-mesh. Wonderful.
But what is that?! Why the unit became so strange? Ouch! Normals! My old normals-textures doesn't work correctly!! What should i do?? Create normals AGAIN with new options?? Well It's not a big problem though if normals created just by using Nvidia Normal filter. But what if normals created manually - in Zbrush or in Max or in other 3d - application? In this case - recreate normals is a big problem and waste of time...

I have a 2 proposition in connection with described above.

1. It is necessary to "teach" tools work with the {Invert X ; Invert Y } normal textures. Tools already can work with the {; Invert Y } (at defaults) and {Invert X ; } ( at

tang[i]+= tangent * (-1) ; tang[j]+= tangent * (-1) ; tang[k]+= tangent * (-1) ;

).
How could it be done - I honestly, don't know, because when I tried something like

tang[i]+= tangent
tang[j]+= tangent * (-1)
tang[k]+= tangent * (-1)

or

tang[i]+= tangent * (-1)
tang[j]+= tangent * (-1)
tang[k]+= tangent

normal-textures goes completly wrong, VERY WRONG if i can use such a phrase.

2. Make the menu-options or something like that, inside tools user interface in which user could define the type of normal-texture he wants to use.
a. (Standart)
b. (Invert X)
c. (Invert Y) /now used in Mesh/Cas/Engine/
d. (Invert X ; Invert Y) /used in grumpyoldman's mesh2ms3d_beta18/

[johnwhile]

no
tang[i]+= tangent * (-1)
tang[j]+= tangent * (-1)
tang[k]+= tangent

is completely wrong, you must change the direction here:

Spoiler Alert, click show to read: 

        for i=1 to numVertex do
        (
            local v = verts[i]
            local n = normalize norm[i]
            local t = normalize tang[i]
            local b = normalize bitang[i]
            
            --ortogonalizzazione di Gram-Schmidt di primo ordine
            t = normalize ( t - n*(Dot n t))
            --ortogonalizzazione di Gram-Schmidt di secondo ordine
            --if det!=0 then b =normalize ( b - n*(Dot n b) - t*(Dot t b)) else b = cross n t
            b = normalize (cross n t)-- il vettore Binormal è sempre ortogonale =  NxT

            tang[i] = t
            bitang[i] = b
            norm[i] = n
        )

example with:
tang[i] = -t
bitang[i] = -b
norm[i] = n

But now attention, i used the uvw conversion (3dstudio - game) after compute tangent and not before:

Spoiler Alert, click show to read: 

            for f=1 to numfaces do
            (
                --FACES
                Faces[f]+= [preVert,preVert,preVert]
                
                local fnormal = normalize (getFaceNormal tmesh f)
                local i = Faces[f].x
                local j = Faces[f].y
                local k = Faces[f].z
                
                local v1 = verts[i]
                local v2 = verts[j]
                local v3 = verts[k]
                
                local uv1 = tvert[i]
                local uv2 = tvert[j]
                local uv3 = tvert[k]
                
                -- Mirror V issue
                uv1.y = 1.0 - uv1.y
                uv2.y = 1.0 - uv2.y
                uv3.y = 1.0 - uv3.y

                local dV1 = v2 - v1 --[x1,y1,z1]
                local dV2 = v3 - v1 --[x2,y2,z2]

So try please and tell me if you see some inverted texture in game or if the normals texture are changed.

[kompadre]

Sorry for coming late.
I just begin testing.

Good NEWS Everyone! (C)

------
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent

++

tang[i] = -t
bitang[i] = b
norm[i] = n
-----

That's = INVERT X ; INVERT Y for normals options !!!

------
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent

++

tang[i] = t
bitang[i] = b
norm[i] = n
-----

As I said before
That's = ; INVERT Y for normals options !!!

------
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent

++

tang[i] = t
bitang[i] = -b
norm[i] = n
-----

That's = Standart = Invert NONE for normals options !!!

Last test I run twice. With simple-gray diff-texture, and then with usual diff-texture. All Uv's on it's proper places - and all is good!



Try to

------
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent

++

tang[i] = t
bitang[i] = b
norm[i] = -n
-----

And had a strange results - units became much darker...


But why I still testing?
We already has the

------
tang[i]+= -tangent
tang[j]+= -tangent
tang[k]+= -tangent

++

tang[i] = t
bitang[i] = b
norm[i] = n
-----

That's = ; INVERT X for normals options !!!



So, we have All POSSIBLE options for normals

[kompadre]

This is unit with proper normals (see attachments)

[johnwhile]

So these options:

tang[i] = t
bitang[i] = -b
norm[i] = n

correspond to standard options of nvidea plugin ? so i will set as default value for next release?

PS1: In the previous message i said don't change this code:
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent
because the last code ( t, -b , n ...) is the normalization and summary of all calculations

PS2: Normal vector (n) MUST NOT BE CHANGED, it define the orientation of all faces, example in 3dstudio invert normal correspond the "Flip" operation in the Editable_mesh, and in game you can see invisible face !!!

My only problem was to understand how these two vectors (tangent and binormal) had effect, i read that T and B are used for shaders: http://en.wikipedia.org/wiki/Shader but the real function is always a mystery for me, because i'm not a 3d programmer....
About UV coordinate system there are a lot difference between programs, also for world coordinate system XYZ.
Example : 3dstudio use Z as height, milkshape as wight, game(OpenGL) as length ecc... , 3dstudio's uvw are equal to milkshape (0,0 = bottom , left) but game (OpenGL) use a different system and also nvidea plugin...

All these to tell you that the only solution to convert correctly the values is testing in game and see if the correction is right

[kompadre]

So these options:

tang[i] = t
bitang[i] = -b
norm[i] = n

correspond to standard options of nvidea plugin ? so i will set as default value for next release?

Yep
and it corresponds 3dMAX default settings
But....
As I said the oldest tool from grumpyoldman uses

Invert X ; Invert Y ...

So, I Offer, first of all, to represent all options and particularly for the Invert X ; Invert Y make a remark - "Options used in mesh2ms3d_beta18"

PS1: In the previous message i said don't change this code:
tang[i]+= tangent
tang[j]+= tangent
tang[k]+= tangent
because the last code ( t, -b , n ...) is the normalization and summary of all calculations

All right.
Then I must find The Invert X..

I think it'll be

tang[i] = -t
bitang[i] = -b
norm[i] = n

But it need to prove by tests...

My only problem was to understand how these two vectors (tangent and binormal) had effect, i read that T and B are used for shaders: http://en.wikipedia.org/wiki/Shader but the real function is always a mystery for me, because i'm not a 3d programmer....
About UV coordinate system there are a lot difference between programs, also for world coordinate system XYZ.
Example : 3dstudio use Z as height, milkshape as wight, game(OpenGL) as length ecc... , 3dstudio's uvw are equal to milkshape (0,0 = bottom , left) but game (OpenGL) use a different system and also nvidea plugin...

All these to tell you that the only solution to convert correctly the values is testing in game and see if the correction is right

Hmm. I think i can't just now to clarify All About B and T.

But for that invert options.
I think All simple.
Where is the UV origin point?
Let say the default is (0 ; 0) = LOW,LEFT
THEN
INVERT X;Y is (1,1) TOP,RIGHT
INVERT X is (1,0) LOW,RIGHT
INVERT Y is (0,1) TOP,LEFT

It doesn't matter (where is origin) for the diff(color) - textures. But for the normals - it's important.
That's how I understand

[kompadre]

So

tang[i] = -t
bitang[i] = -b
norm[i] = n

is definitely corresponds to INVERT X

By the way, I attached (in this post) two files which allow you to test normals and normals options.

First file is for color-texture (diff) (named TestPureGreyDiff.psd) - this is simple grey-texture sheet without anything else.

Second file is for normal-texture (norm) (named TestGrid.psd), BUT it's now NOT NORMAL-TEXTURE it's White tiles with black grooves.
From TestGrid.psd you can do 4 normal-files with different Invert options. Use Nvidia Normal Map Filter to do that. In Nvidia Normal Map Filter you can find some other options.
I usually use :
1. minZ = 0 ; Scale = 5.5 ;
2. Filter type = 4 samples
3. Height Source = Average RGB
4. Alpha field = Unchanged
5. 3d view options = doesn't matter
AND IMPORTANT
6. Wrap ; Invert X ; Invert Y ; Invert Z.
I don't work with Wrap and with Invert Z. Leave them as defaults (unchecked)
But 2 options Invert X and Invert Y give us 4 variations -
1. Unchecked Invert X;Y = Standart
2. Checked Invert X = Invert X ;
3. Checked Invert Y = Invert Y ;
4. Checked Invert X ; Invert Y = Invert X ; Invert Y
That means - you can obtain 4 normal-textures (from TestGrid.psd) with one sense (tiles with grooves) but different options.

Then you may convert textures into dds->game.texture.
And then apply TestPureGreyDiff to game-diff, and one of obtained normal to game-norm and test!.

If you see perfect tiles with grooves (glazed tile) then unit uses the same normal options as in tested normal-file.
If you see completely vice-versa (extruded grooves/hollowed tiles) then unit uses opposite (INVERT) options (for example: normal file uses INVERT X ; INVERT Y - then opposite options is STANDART (INVERT NONE) )
if you see some extruded tiles, but some hollowed - then only one of normal-option in unit inverted from normal texture (X or Y).


P.s. Attached textures is 2048x2048 - you can use in that resolution in the game or in standart 1024x1024.
If you want standart, you must resize (in photoshop for example) my textures.

[johnwhile]

http://wiki.polycount.com/NormalMap#T
there are some information but i don't understand that is invert x/y, is possible the light direction ?
i will add in the next script fix the options:

INVERT XY (1,1 - TOP,RIGHT) = mirror UV
INVERT X (1,0 - LOW,RIGHT) = mirror U
INVERT Y (0,1 - TOP,LEFT) = mirror V

here: http://stackoverflow.com/questions/8...uv-coordinates
he said that opengl (the game) use lower-left corner like 3dstudio, so is correct.

[kompadre]

http://wiki.polycount.com/NormalMap#T

Good tutorial, but...
Many letters ...

there are some information but i don't understand that is invert x/y, is possible the light direction ?

Normals (Tangent-space) - set the object relief. Folds/wrinkles... Normal map don't change the real geometry/topology But it change reflected light thus light behavior become as if object REALLY (in geometry/topology) has relief (or folds or whatever tangent space is represent).
Because of that the answer = yes, is possible that normals strongly change the reflected light direction (). But it must be very strange normals...

here: http://stackoverflow.com/questions/8...uv-coordinates
he said that opengl (the game) use lower-left corner like 3dstudio, so is correct.

I think if we can test - then we must trust our own eyes .
May be Opengl libraries uses standart options, but medieval 2 theoretically can invert UV origin BEFORE that libraries begins to work...