code FEATURE: OpenGL 3 Renderer

[Almightygir]

The high poly can be in whatever format you like, that part is irrelevant. But outside of that, it seems correct enough.

 

 

Well, with the latest dotXSI exporters which fixed vertex normals... the GLM vertex normals (as displayed in ModView) exactly match the dotXSI and native 3dsMax mesh vertex normals... and the UVs appear unharmed as well.

 

but do the TANGENTS display correctly?

[Archangel35757]

The high poly can be in whatever format you like, that part is irrelevant. But outside of that, it seems correct enough.

 

 

 

 

but do the TANGENTS display correctly?

There is no TANGENT data in the dotXSI or GLM formats, right? So the only way would be if XSIModTool has a method to show tangent space normals... I suppose you or @@Xycaleth could modify his new ModView code to give an option to display tangent space normals for the loaded GLM model as the rend2 renderer would compute them in-game (I think this should definitly be a feature in the next version of ModView).

 

I found a Maxscript in this CGTalk thread that computes and shows the tangents and binormals in the 3ds Max viewport-- I have no idea if this method matches how xNormal or rend2 computes them so most likely the script would have to be updated. The full script is listed for viewing... maybe you could take a look at it?

 

http://forums.cgsociety.org/showthread.php?t=407814

 

EDIT: I had to dive into the Wayback Machine to find the referenced terathon.com webpage. Looks like it's based on the method in this book:

 

http://web.archive.org/web/20061119113206/http://www.terathon.com/code/tangent.php

"Mathematics for 3D Game Programming & Computer Graphics", 2nd ed., sec. 6.8.3, by Eric Lengyel.

[Psyk0Sith]

@@Psyk0Sith you probably don't have all the maps for Gorc to use PBR made since it wasn't something we were going to do originally, I'm sure you at least have a normal and AO since you seemed to have baked those into the diffuse to give detail to the vanilla render engine.

 

Correct, only AO and normals for now.

[minilogoguy18]

@@Archangel35757 Here is Gorc after a tangent property is applied, Mod Tool does support tangents and binormals.

 

 

http://softimage.wiki.softimage.com/xsidocs/import_export_xwalk4xsi_SupportedSceneElementsandAttributesfordotXSI.htm

 

There's some technical jargon but it seems that the older dotXSI does support tangents just storing it under color at vertices rather than preserving the operator but that is probably only a big deal if you were re-importing back into Softimage where you would want to preserve scene structure.

[DT.]

Ok I'm going to ask this, because this whole no tangents in GLMs is starting to shit me off.

 

@@Xycaleth, how exactly hard would it be to add support for storing tangents in GLMs?

[Xycaleth]

Not very. It's just storing one more field per vertex, and reading one more field in the renderer.

[minilogoguy18]

@@DT85

 

[Almightygir]

you know, you could have asked me that too

 

store vert data as a struct, add new entry to struct, profit.

[Archangel35757]

@@Xycaleth, @@DT85 - I for one am against modifying the GLM format. It breaks compatibility with Carcass, and all legacy importers & exporters for all 3D packages.

 

We don't even know the results of exporting XSI files and baking normal maps in xNormal from the XSI files-- this could yield near-perfect results; and if that pipeline works out then modifying the GLM file is unnecessary. I think the results of @@AshuraDX's Clone Trooper are shit hot and it's very difficult to see any flaws... I dare say the standard player [and myself included] would be able to find the flaws that experts like @@Almightygir can see after the model spins around several times-- especially in a fast paced shooter game like JK. I still don't "see" the flaw he referred to on the clone trooper ass.

[minilogoguy18]

Ummmm, @@Archangel35757, compatibility is something we don't care about since this is a stand alone mod. MP is out the window and we have no need to import our assets back since we'll be in possession of all the source files since we're the creators. I have no doubt that you or @@DT85 could modify the importers to allow these files to come back but there is almost no need to other than maybe checking against the original to see normals and such.

 

I have lived all these years without a GLM importer, it's not a big deal since I'm not trying to use other peoples work. We have the carcass code, it's what's also going to have to be modified to write the proper file and I'm sure DT is aware of it.

[Archangel35757]

@@minilogoguy18 -- It's easy for you to say "...it's no big deal to change GLM importers and exporters and update Carcass..." but this isn't on my ToDo list. The Carcass source code was intrusted to an individual in confidence... and any such major change would likely not go un-noticed; shouting "we have the code" may get that source in trouble (and kill ever getting any further resources)-- so please try to be discreet.

 

Please take in-game screenshots of @@AshuraDX's clone trooper and point out the normal map flaws (you too @@Almightygir). Everyone was thrilled with the Clone Trooper results until @@Almightygir comes along and says, "...it's good but not perfect."

 

And we haven't even thoroughly investigated the dotXSI/xNormal-->GLM workflow.

 

Furthermore, am I correct to say that Normal maps are NOT going to get baked using GLM meshes? Right? Baking would use FBX, OBJ, or XSI, yes? So it's those formats that need to store the tangent basis vectors (FBX already does)... yes? So you would need to copy the tangent basis vectors from the FBX or XSI files and carry that data thru the GLM conversion and write it into the GLM format, right? And like I said earlier Ghoul2 is a half-precision format (based on XSI single-precision format). So how does that compression affect the mesh data?

 

With ALL the work that DF2 mod has to do... it seems like vanity to pursue this course until the other workflows are shown to be inadequate.

[minilogoguy18]

I'm already familiar with xNormal and it's ability to import a dotXSI file, it works just like importing a .obj or any other 3d format. You import the high and low resolution models setup your options, what maps you want to create and it will generate them. With a basic tutorial I found online a couple of years ago it was all pretty simple to follow. The end results really depended on your models and how well they were made but that's the same no matter what you're using to bake maps.

 

I originally was using ultimapper in Softimage to do that sort of thing but xNormal was able too generate the maps faster and didn't require as much tinkering also with so many people using it I was able to find some "generic" settings to get some good results.

[DT.]

Well how about we ask @@Scooper to give us the source for his glm exporter, add in tangent storing. Then add reading it to the renderer. If something goes wrong, we won't have modified the dotxsi exporters or carcass.

 

If it works however, we can then edit the dotXSI exporters and carcass. Could add a switch for carcass to convert to this new, "Ghoul3" format.

[minilogoguy18]

If you're current 3DS Max dotXSI exporter doesn't support tangents then it isn't a actual working exporter since the format is supposed to support tangents. I'd hate to see a GLM exporter come along and not a way to improve dotXSI->GLM since I would go from the most reliable and capable exporter to nothing at all.

[Archangel35757]

Well how about we ask @@Scooper to give us the source for his glm exporter, add in tangent storing. Then add reading it to the renderer. If something goes wrong, we won't have modified the dotxsi exporters or carcass.

If it works however, we can then edit the dotXSI exporters and carcass. Could add a switch for carcass to convert to this new, "Ghoul3" format.

@@Scooper wouldn't give me the source code to compile the GLM exporter for Max6 thru Max2011. I fully understand his position (and reluctance). I imagine he would have to be the one to change it... and keep his source closed.

 

How about we thoroughly investigate the dotXSI/xNormal baking --> GLM conversion... and then determine if the results are spectacular or not? And then go from there... are the results from Ashura's workflow unacceptable as-is now? It looks great to my untrained eye.

 

I still want @@Xycaleth or @@Almightygir to answer my questions above... especially about if it's the FBX or XSI that needs the tangent basis vectors (because those are the formats the normal maps will be baked from).

[Teancum]

Isn't this all a bit "cart before the horse?" I mean a first demo hasn't been released and all energies are being put into major rendering improvements. Seems like a lot of focus on tech that doesn't have the workforce behind it to utilize the improvements. Going all "Ghoul3" would mean a re-export of every model with all these optimizations. I mean I guess there's only so much that can be done when there's not a lot of interest in mapping.

 

Then again, I suppose that's the beauty of modding. There are no milestones -- you just work on what makes you happy.

[Archangel35757]

@@minilogoguy18 - Softimage's native format stores the tangent basis vectors but I don't think the XSI format does-- I can't find any native template; but it would be possible to store the data in a generic custom user data template. You could export a dotXSI and see if it is in the resulting file.

[AshuraDX]

Well how about we ask @@Scooper to give us the source for his glm exporter, add in tangent storing. Then add reading it to the renderer. If something goes wrong, we won't have modified the dotxsi exporters or carcass.

 

If it works however, we can then edit the dotXSI exporters and carcass. Could add a switch for carcass to convert to this new, "Ghoul3" format.

@@Scoopers exporter has other flaws that need to be fixed first. Like the Lack of LOD Exporting and randomly split edges across the mesh, if I recall correctly. It's been a while since I used it.

 

EDIT: here's something I prepared for @@SomaZ yesterday: https://www.dropbox.com/s/9oy1fxh00s3zxh3/JKA_GL2_TestMats.rar?dl=0

These are 10 Sample Materials from Substance Designer 5.6 exported for GL2

and my fanned cobblestone Material: https://www.dropbox.com/s/9ygrfzaqme430xd/cobble_GL2.zip?dl=0

 

All of these are setup with a heightmap in the normalmap alphachannel for parallax mapping.

[minilogoguy18]

@@Archangel35757 if you do a quick google search or open the help files with any version of Softimage including Mod Tool it shows that tangents are supported in the dotXSI format. I already posted a link to it.

 

@@Teancum, we could release a demo any time honestly, it would be a 1 level demo but we do have 1 fully playable with no bugs level. Once DT started learning more and more about coding all these great things happened.

[Almightygir]

@@minilogoguy18 -- It's easy for you to say "...it's no big deal to change GLM importers and exporters and update Carcass..." but this isn't on my ToDo list. The Carcass source code was intrusted to an individual in confidence... and any such major change would likely not go un-noticed; shouting "we have the code" may get that source in trouble (and kill ever getting any further resources)-- so please try to be discreet.

 

Please take in-game screenshots of @@AshuraDX's clone trooper and point out the normal map flaws (you too @@Almightygir). Everyone was thrilled with the Clone Trooper results until @@Almightygir comes along and says, "...it's good but not perfect."

 

And we haven't even thoroughly investigated the dotXSI/xNormal-->GLM workflow.

 

Furthermore, am I correct to say that Normal maps are NOT going to get baked using GLM meshes? Right? Baking would use FBX, OBJ, or XSI, yes? So it's those formats that need to store the tangent basis vectors (FBX already does)... yes? So you would need to copy the tangent basis vectors from the FBX or XSI files and carry that data thru the GLM conversion and write it into the GLM format, right? And like I said earlier Ghoul2 is a half-precision format (based on XSI single-precision format). So how does that compression affect the mesh data?

 

With ALL the work that DF2 mod has to do... it seems like vanity to pursue this course until the other workflows are shown to be inadequate.

 

I think i'm confused... you keep referencing the DF2 mod, i thought that was a separate entity to this? Xycaleth seemed to make that assertion anyway.

 

As for me coming along and saying "it's not perfect". Sorry bro, i'll let you live in your world of rainbows and butterflys. Adding a new field to the GLM format won't affect backward compatibility, the renderer will attempt to read tangents in files that dont have them, it will return null, and it will calculate its own. Worst case scenario, a tangent calculation will need to be added to the renderer to supply meshes which don't contain it, with it.

[Archangel35757]

@@Almightygir - All the tools that would require updating affect everybody-- not just DF2. And respectfully, you didn't answer my question. From where will the tangent basis vectors be computed/written into the GLM file? If you compute it from its own GLM mesh and UV data... how does the half-precision compression factor into that? Secondly, the GLM mesh would not be used to bake the normal map, right? That would be either OBJ, FBX, XSI, right? So is it not one of those formats where it is crucial to have the tangent basis vectors written?

 

@@minilogoguy18 - look a little more carefully at the link you provided... it clearly stated, "...The following tables list the features supported when importing into and exporting from Softimage using the dotXSI 6 (*.xsi) format." Carcass supports dotXSI 1.1, 1.3, 3.0 and 3.5 formats-- and not 5.x or 6.x. So export out Gorc, with tangent data applied, as dotXSI 3.5 and 6.x and compare the two resulting files-- send them to me to check also.

[Xycaleth]

Just to point out - normals in the GLM format aren't written as half-precision (actually, nothing is). Normals are written as full 32-bit floats. @@Archangel35757 your confusion may come from bone data which uses fixed-precision numbers, which can be less accurate for small numbers.

 

I still don't fully understand why the tangent vector needs to be stored in the model itself, but here's what I understand so far. Hopefully others will find it useful.

• For a normal vector, there can be any number of tangent basis vectors. As long as these vectors are perpendicular to the normal, then you can consider them basis vectors.
• For this reason it's useful to define a standard method to compute these vectors - this is what mikktspace is. Given a model and its vertices, regardless of triangle ordering, or ordering of the vertices in each triangle, the mikktspace algorithm will always produce the same tangent vectors.
• Normal maps created from hi-poly models will need to create its own basis vectors during the generation process. Rendering a normal-mapped model, using different basis vectors can cause artefacts.
• Therefore, you want to store (or alternatively calculate at load time) tangents created from the model. mikktspace gives the same vectors for a given mesh so is a good candidate.
• You probably want to store the tangents instead of calculating them at load time because it looks to be more time-consuming than other simpler methods.
• Even if mikktspace is not used, storing the tangent in the model means the renderer will use the same tangent vectors as those used when generating the normal map.

Hopefully @@Almightygir can tell me if I've missed anything here or said anything wrong. I don't fully understand all the problems, but the reasoning for storing the tangent vector in the file makes sense to me.  I think someone else mentioned in an earlier post that an auxiliary file containing the tangents could be produced. This seems like a good way to go if you don't want to change the GLM file format.

 

Anyway, I would say, if you have more important features you want to add to your renderer then ignore this problem for now and come back to it later It's no use having perfect normal/tangents if everything else looks bad

[Archangel35757]

@@Xycaleth - thanks for the clarification. But my question remains... what is the point of storing tangent basis vectors in a GLM mesh file-- if the GLM mesh file itself is not used for the normal map baking process?

 

If the normal map is baked using FBX, OBJ, XSI... isn't it those formats where it's desirable to compute or store the tangent basis vectors? Then those FBX, XSI, etc. tangent basis vectors would need to be carried over and written into the GLM mesh (and not computed from GLM directly), or am I misunderstanding?

[Almightygir]

If storing tangents directly in the .GLM file is undesirable, as long as they can be reliably stored in a secondary file (.GTB for example, Ghoul Tangent Binormal) and read by the renderer, i don't see a problem.

 

@@Xycaleth, seems spot on to me.

[Archangel35757]

@@Almightygir - we posted at same time... so maybe you missed my last question. I would still like for you or @@Xycaleth to clear away my confusion.