Archangel35757

@@DT85 - Did you overlook what I wrote? "...We haven't come up with the *.GBT format yet... it could be made to look exactly like the FBX tangent/binormal data in an ascii FBX file. In which case you could construct the *.GBT by copy/pasting the data out of the FBX. Therefore you wouldn't need to update FBX2GLM." ...and Carcass could write it out the same way (matching the extracted FBX format) from reading the dotXSI data.

I'm not understanding you... why prevent people from using an FBX lo-poly file for the bake? Just need to run it thru an updated FBX2GLM to get the *.GBT file. Then you still use the GLM/GLA from Carcass... you still have a sync'ed workflow. And you have a sync'ed workflow for dotXSI/xNormal-->Carcass(updated) We haven't come up with the *.GBT format yet... it could be made to look exactly like the FBX tangent/binormal data in an ascii FBX file. In which case you could construct the *.GBT by copy/pasting the data out of the FBX. Therefore you wouldn't need to update FBX2GLM.

@@UniqueOne - FBX is not a game-engine friendly format as I understand it... We have a path forward... and like @@Almightygir explained many pages earlier-- it is important to have a sync'ed workflow. This will apply to MD3 models as well.

@@UniqueOne - go back and start reading from page 10. we have a path forward... we just need a few details.

@@UniqueOne - wow... I thought I wrote long posts. I can't answer everything you asked... but yes, we are talking about a supplemental file format called *.GTB (Ghoul2 Tangents Binormals) that the renderer would read in conjunction with a standard GLM file.

I'm not disagreeing with you. But first we need to hear back from Santiago or Grant from xNormal to know if they even used that tangent data written in the "COLOR" property of a dotXSI file when baking maps with a low-Poly dotXSI file. They might not have known about it since it's obscure and written as vertex "COLOR" data (remember earlier when @@Almightygir said, "...You absolutely should NOT store tangents or binormals in vertex colors as those are often capped at half precision.") ...but luckily dotXSI stores them as float values-- however, instead they more likely computed it themselves using the triangle's face normal and the vertex's (s,t) UV data. So we have to know exactly what they did and do likewise. Is xNormal the only "mikktspace" baking tool that supports the dotXSI format? Also, we will still need to update FBX2GLM so that it copies the FBX tangent data out to a *.GTB file for those artists who want to bake maps with an FBX low-Poly mesh-- to maintain a sync'ed workflow, right?

@@minilogoguy18 - he was not saying to abandon Carcass... even if that tool is updated to compute a *.GTB file based on the dotXSI file (normals, UVs, tangents, whatever-- I've asked the xNormal developers some questions regarding their dotXSI mesh importer and how xNormal used it)... as @@Almightygir stated, it's having a sync'ed workflow that is important. So if Carcass computes a *.GTB file for the Rend2 renderer it means the normal maps, etc. need to be baked with that low-poly dotXSI file. And for folks who used FBX for their baking... they would have to run their FBX thru @@Xycaleth's updated FBX2GLM tool to get a *.GTB file. What's wrong with that? It's a minor change to two tools (...plus an additional change for the Blender exporter). That is a lot simpler, and less intrusive, than modifying the GLM format in my opinion.

I do agree that his tool should be updated to generate this *.GTB file from an FBX for use by the rend2 renderer. But we still need Carcass and dotXSI files to generate the Ghoul2 .GLA animation file. It's the only tool available (besides Blender) to compile Ghoul2 animations. @@Xycaleth's FBX2GLM converter only creates a static GLM mesh file... and I'm not sure if it handles LODs-- others would know. So non-Blender users would still be able to use the GLM file produced by Carcass, right? This forces the pipeline to use only FBX for normal and cavity maps, right? (do AO maps need this data?) So that everyone knows, I wrote an email to Santiago and Grant asking if they would release to me the their deprecated dotXSI mesh importer plugin source code...

3 cases: 1. Binormals only 2. Tangents only 3. Tangents and Binormals. I'm somewhat confused because I don't see how the COLOR RGBA float value can store two vectors unless it appends one set at the end of another. My hunch is that it only ever writes out the "tangents" to COLOR and it expects the binormal to be created from cross product of triangle face normal and tangent vector... but you can prove me wrong. Oh, and these need to be triangulated meshes as I understand it.

It's also about seeing if the dotXSI file and it's tangent data stored under the SI_Shape template's COLOR property is used at all by xNormal-- if not then there is no point to updating the dotXSI exporters. We were wanting you to take @@Psyk0Sith's box files and see if you produce the same or different normal map... when you add the tangents property to dotXSI 3.5.

You've got 4 meshes that are not parented correctly. Do you have any hidden junk meshes? All the meshes should be linked under Stupidtriangle_off, yes? look at a working model in Modview for comparison.

Yeah, I deleted it... because @@Psyk0Sith says it was not a good candidate and too complex to fix. Testing should use his Box test files he linked to in one of his earlier posts.

Would you do a quick check using the sample jaiqua scene... and add only "Binormal" and see what (if anything) it writes into the "COLOR" property in the SI_Shape template?

@@Almightygir - so from looking at XSIFTK docs... the "COLOR" property is stored as floats- so that's single-precision, yes? Also, check your PMs. @@minilogoguy18 - I did not see a "Binormal" property in XSI Mod Tool 6-- only a "Tangents" property. Can you confirm? Maybe this only stores the tangent vector in "COLOR" and they expect you to compute binormal from cross product of face normal and tangent???

that would be cool too. But I was referring to an EFX or something to make the droplet impact effect.

By "options" I assume you are referring to the 2 "Pick" buttons. I did apply the Binormal option just above the tangent option... it created a "binormal" CustomPSet... but like I said... doing a pre-/post- comparison of the two resulting XSI 3.5 files... adding Binormal didn't change any values under "COLOR" parameter. Should it have?

Then please tell me how xNormal knows to use tangent basis vectors stored in FBX (or dotXSI) format? Can you take a screenshot of that? Because I just looked thru the options and plugin configuration settings and nothing jumps out at me that says "use mesh tangent data" ...in the Tangent Basis Calculator config settings, I only see a checkbox for "Compute binormal on the fly in the shader." All I see that might be relevant is the "Ignore per-vertex-color" checkbox in the Hi-Def mesh's section (but you say that's not applicable). And "Match UVs" and "Highpoly normals override tangent space" checkboxes in the Low-Def mesh's section.

@@minilogoguy18 - so I loaded the sample jaiqua female mesh in Softimage and applied a Tangent Property to the mesh... It gives options to pick different sources for UVs and Tangents-- I'm not sure how that aspect works and what you would pick from (...the Hi-Poly mesh? I don't know...) ... Like you said, it writes out a CustomPSet template denoting it has tangent data (as stored in the vertex COLOR parameter): XSI_CustomPSet Jaiqua_Mod.low-res.Tangent { "NODE", 2, "Texcoord","Text","Texture_Support", "Tangents","Text","Tangents", }...and it wrote these tangent vectors under the SI_Mesh templates vertex "COLOR" parameter. Like so: 8438, "COLOR", -0.298336,0.047644,-0.953271,0.342933, -0.681604,-0.195287,-0.705180,0.304814, -0.879368,-0.230859,-0.416431,0.342933, -0.565923,-0.497810,-0.657203,0.342933, * * *...and in the SI_TriangleList where it stores the vertex ID reference it added the COLOR parameter as well. SI_TriangleList Jaiqua_Mod.low-res { 4130, "NORMAL|COLOR|TEX_COORD_UV0", "DefaultLib.Material1",So I exported the file out again as dotXSI 3.0 (same settings) and it fails to write the Tangent CustomPSet template... however, it DOES include the COLOR parameter in the SI_Mesh and SI_TriangleList... it just writes the values as zeroes. So on the 3ds Max side of things... the minimal effort would be to simply add the CustomPSet template and fill in the COLOR data correctly. Because it's a shit-load of work to rework the exporter to overhaul the material templates due to major changes in the dotXSI 3.5 materials. I do recall seeing xNormal options for using vertex color-- but I don't know if this is how xNormal knows to use that data for the tangent basis vectors or if it's expecting something else... @@Psyk0Sith, @@Almightygir? EDIT: @@minilogoguy18... ok, I went back and also saw the Binormal property like you pointed out; so I added it, re-exported dotXSI 3.5, and it generated the following custom template: XSI_CustomPSet Jaiqua_Mod.low-res.Binormal { "NODE", 2, "Texcoord","Text","Texture_Support", "Binormals","Text","Binormals", } However, when I compared the two dotXSI 3.5 files... this "Binormal" change did not modify the numbers at all written under the "COLOR" info. So I find this a bit disconcerting (of course I don't know what I'm doing or if you are suppose to use the "pick" features, etc.)

I do... but I don't trust myself to add the tangent space data correctly. I'm searching the sdk help and docs now... would be nice if you could email me your 3.5 file with the customPset data.

@@Psyk0Sith - good job. Ok... so those dotXSI 3.0 files were produced with the v1.9 exporter, correct? What export vertex normals option did you use? What were your xNormal settings? Now you need to send those low-/hi-poly dotXSI files to @@minilogoguy18 (unless you have Softimage or ModTool) so that (you or...) he can add the inherent tangent basis vectors that Softimage can export into a dotXSI 3.5 file (without making any other mesh changes...); then we need to determine if there are explicit settings in xNormal to bake the normal map from the dotXSI internal mesh tangent data (rather than xNormal computing the normals on its own)... am I correct so far? @@Almightygir ?

@@Xycaleth - great work! ...but it was difficult for me to tell from the video-- does it include a droplet impact/splash EFX?

@@DT85 - Maybe I could use your Kyle head (only the head...) to get started on the new facial gla rig? I think there should be a male/female version... and possibly each unique alien would have its own as well. Or maybe it should be based on a male head that conforms to the Golden Ratio Rule using the distance between the eyes from the JK skeleton. The problem with the legacy SoF2 facial bones is that they are skewed off in the X axis and are not symmetrical about the ZY plane. I wonder how it would affect legacy meshes if the bones on left side of face were moved to be symmetrical? Because based on my research, their placement is pretty good and could be used if made symmetrical.

Ok... yes, I'd like to see SSS and wrinkle maps too. Lets see what @@Psyk0Sith and @@minilogoguy18 get with the dotXSI/xNormal 3.17.16 normal map baking process. Also, @@Psyk0Sith wants to simplify the test model... boil it down to bare essence.

@@DT85 - We don't even know yet, if xNormal even uses the internal tangent data stored in a dotXSI 3.5 file. I just tried with the low & high poly dotXSI files I sent you and I don't see anything jumping out at me in the xNormal settings-- It has a check box to use exported normals (but that's vertex normals)... and it has a check box to either ignore (or not) vertex colors... and HiPoly mesh normals override tangent space on the lowPoly, etc. I'm not seeing anything that says anything close to "use mesh tangent data" @@Almightygir? xNormal could really use some help documentation. If xNormal doesn't use this internal dotXSI tangent data... then it's pointless to consider updating the dotXSI exporters and Carcass... would you agree? You say, "...100% proper looking assets..." -- so what percentage do you score @@AshuraDX's Clone Trooper? No one has yet pointed out what is unacceptable with his clone trooper results... nor have we investigated dotXSI/xNormal-->Carcass (v2.2)-->GLM-->In-Game process yet. These results may be acceptable... we don't know yet. If these results are in the 90% range or higher... is it worth all of this extra coding effort-- to squeeze out a few more percent? Could we discern the visual difference when players are running around shooting and sabering NPCs? EDIT: @@DT85, a few days ago (22 Feb) you stated: Are you no longer happy? And what about MD3 models? Are you ok with just letting the renderer calculate the tangent basis vectors for MD3 models as is currently done? Aren't most of the environment models players are going to be looking at be MD3 format? I guess I'm just saying it's a lot of work and it may not yield any appreciable difference in results.

From my understanding of what @@Almightygir and @@Xycaleth were saying... the tool that actually computes the tangent basis vectors (by the way... I vote for *.TBV [Tangent Basis Vectors] file extension) that are used to create the normal map, should be the tool that writes out those tangent basis vectors to the *.GTB or *.TBV file... but not everyone will use xNormal, right? Then again, not everybody uses Carcass either ( hello, Blender people ). Are we going to force a specific pipeline on the community? Furthermore, Carcass doesn't support the FBX file format... so how will folks who bake their maps using .FBX and some other tool (Allegorithmic, etc.) get their tangent basis vectors used for baking into the final .GLM file? @@Xycaleth did create an FBX to GLM converter (with no animation support)... I guess updating that is one option-- and still use Carcass for compiling the GLA. We are also assuming that xNormal uses the tangent data stored in the dotXSI file-- and this may not be the case! It might not read that internal mesh data and instead compute it on its own from the mesh face's normal and UV data. If this is the case then having Carcass read the dotXSI tangent data that was not used by xNormal will also likely create artifacts, yes? I sent some dotXSI files out by email for @@Psyk0Sith and @@minilogoguy18 to test out. The only way we can know is... if the xNormal 3.17.16 has specific options to select to use tangent basis vectors from the mesh file for the dotXSI format. And if xNormal doesn't use this stored mesh data... then you'd likely get mismatching data and possible artifacts, right? So we're looking at having to update: (1) The Blender GLM exporter, and (2) the FBX-to-GLM converter, (3) Carcass [ for handling dotXSI tangent data-- assuming xNormal uses the mesh's internal tangent data ], and (4) all of the 3ds Max dotXSI exporters to add writing of tangent basis vectors into a Custom template. Does that about sum it up? No one has really pointed out any significant flaws in @@AshuraDX's clone trooper results (somebody please mark up some in-game screenshots to point out these travesties!), and we still haven't investigated the dotXSI/xNormal-->Carcass-->GLM-->In-Game results (with current tools) yet either. So before we go down these coding rabbit holes, I think these results should be vetted. I definitely want to know if xNormal uses the dotXSI 3.5 tangent data or if it computes it on its own before we touch (3) and (4). For which, I will need some help making the secret sauce from either @@Xycaleth or @@Almightygir. EDIT: I suppose there is also the 5th option of writing an export function to allow xNormal to write out the tangent basis vectors it uses for normal map baking (this has the benifit of supporting multiple mesh formats, right?)...and this would be necessary if it doesn't use the internal dotXSI tangent data-- and thus no point in doing (3) and (4) and just go with (5), right? Thoughts on all of this (can you tell I'm an engineer)?