code FEATURE: OpenGL 3 Renderer

[Ramikad]

okay, i'll try to simplify further...

 

in order to bake your normalmaps, you have to either export to fbx, or obj first, because no baker supports GLM. This is mesh "a". Mesh a has a set of tangents that can largely be reliably predicted because the obj format is simple as balls, and fbx is well documented. In either case, we know what the mesh tangents are on export, but we also know they won't be the same as GLM (or can be reasonably sure).

 

once you've baked, you then have to export to GLM, which has a different set of tangents.

 

the renderer would be trying to use a normalmap baked with tangents a, on a mesh whos vertices now have tangents b. the math wouldn't add up.

 

What if I tricked it by getting the non-baked .glm exported, then imported in Blender, bake the normals there and export? Would the tangents mess up even more? Or it's something else you mean?

[mrwonko]

(I don't know if @@mrwonko's GLM exporter for Blender can compile GLA files)

nuff said

[Almightygir]

As long as the mesh tangents on export are not modified in any way by the renderer, i guess that could work.

[Archangel35757]

@@Almightygir- I'm not sure what you mean by exported mesh tangents... yes, FBX stores them but OBJ does not-- you only get vertex normals, correct?

 

With the latest v2.2 MD3 and v1.9 dotXSI3.0 exporters-- the vertex normals in the MD3 and dotXSI files exactly match what is stored inside 3dsMax for the mesh.

 

But like you said, to take the mesh into another normal map baking tool it must be exported to FBX... and then the normal map is brought back into 3dsMax, and then applied to a lower res mesh right? But the low res mesh wouldn't have the same vertex normals (or tangent space normals) as the higher-res mesh anyways, right? @@AshuraDX, @@DT85, @@Psyk0Sith? I've never baked a normal map for a model yet for this game engine...

 

But it's the lower-res mesh LOD0 that is exported for the game as either MD3 or GLM and not the hi-res mesh used to bake the normal map, right? So how does that factor in?

[Almightygir]

Ah i see where your confusion is...

 

When you bake a normalmap, you're projecting the vertex normals of a high poly mesh, to a per-pixel map on a low poly mesh.

 

The biggest problem is with exporting a low poly fbx (which yes, is supposed to store tangents) elsewhere to bake, then export that same mesh as a GLM, and hope that the tangents are the same... it sometimes just goes wrong *because*. literally *just because*. Also, you're correct about obj not storing tangents, however just about every piece of software out there calculates tangents for obj files the same way.

[Archangel35757]

@@Almightygir - so every LOD (LOD0, LOD1, LOD2, etc.) has to be exported out and baked against the hi-res mesh? Or do folks just accept the error and apply the LOD0 baked normal map onto the lower LODs?

 

"...just about every piece of software out there calculates tangents for obj files the same way."

 

And since both MD3 and GLM are well known formats to this engine and renderer, can't Rend2 compute the tangents the same for them? Given people follow a proper workflow?

[minilogoguy18]

I'm sure someone here could do what needs to be done which is add tangent support to GLM files and allow the compiler to properly take all normal and tangent properties from the input file (.XSI or .FBX) to the GLM file. I mean we have the carcass code, FBX code, XSI code and GLM code so why not just update some of the tools and the GLM file type and make it work properly and not half assed?

 

I would really like to see FBX be able to be used by carcass since it can be exported from a wide range of softwares and mainly Maya which is without a doubt the top dog in 3D.

[Archangel35757]

...but is it half-ass now? I don't think so-- I think it's very acceptable now.

 

And if you undertook to update all the exporters and file formats and get an update of Carcass, etc., you have to sync all that between Rend2 and all modeling packages and their exporters... (what coders are volunteering to undertake all of this?) ...whereas it seems simpler (KISS) to let the renderer compute the tangent space normals given proper MD3 and GLM exported files with current exporters and Carcass compiler v2.2.

 

Ghoul2 is a half-precision file format and XSI (and FBX?) are single precision file formats so does that compression impact tangent space normals?

[Psyk0Sith]

The LODs are irrelevant, if your bake came out clean for the highest LOD then it will be fine. The LODs might have some artifacts but it won't blow up your computer. Also, if mikkt syncs with current renderer and .glm then everyone should use Xnormal, if not we can try handplane to get the best sync possible.

[DT.]

Unless someone comes along who can and has the time to add in FBX support in the renderer AND the game code, then it won't happen. The game code is set up to read player models in ghoul2 format, not even MD3 will work (ala quake 3) so it would require a rewrite of alot of things.

 

For example, we have the added bonus of MDR and IQM formats in the renderer. Yes the game can load them (tested in the menus), but still only ghoul2 can be used for player models.

[DT.]

@@Almightygir

 

Would it help if we made a "3ds max tangent basis calculator" plugin for xnormal or would it still not help because of GLM/MD3?

[Almightygir]

The LODs are irrelevant, if your bake came out clean for the highest LOD then it will be fine. The LODs might have some artifacts but it won't blow up your computer. Also, if mikkt syncs with current renderer and .glm then everyone should use Xnormal, if not we can try handplane to get the best sync possible.

 

does xNormal support GLM format? If so then that's indeed what people should use to bake their normals.

[DT.]

Way to skip over my two posts....

 

 

No, xNormal doesn not support GLM but someone could make a plugin for it.

[Archangel35757]

@@Almightygir

 

Would it help if we made a "3ds max tangent basis calculator" plugin for xnormal or would it still not help because of GLM/MD3?

 

...No, xNormal does not support GLM but someone could make a plugin for it.

 

xNormal has exporter plugins that support 3dsMax, Photoshop, and Maya that exports XNormal's own mesh format (.SBM).  The older version of xNormal (v3.17.16 ...no longer available to download from xNormal.net) supports older versions of 3ds Max (Max7-2013) and Maya (8.5-2013). I will upload it to Utilities shortly.  XNormal also supports the dotXSI file format (...but it doesn't like mesh objects without texture coordinates-- meaning you must do an ExportSelected from 3ds Max and omit the bolts/tags and Stupidtriangle_off).

 

@@Almightygir, @@Psyk0Sith  - since XNormal directly supports importing dotXSI mesh files, and we export dotXSI files to be compiled into Ghoul2 models using Carcass... I would recommend that we create the normal maps using the exported High-/Low-Poly meshes in dotXSI format and import the dotXSI files into XNormal for normal map baking... it has options to use exported normals (as written in the dotXSI file).  Seems like the best option since Carcass compiles all the dotXSI files into Ghoul2 GLM/GLA, yes (...at least for 3ds Max, Softimage, Maya workflows)?

 

XNormal v3.17.16 supports the following mesh formats:  FBX, Silo ASCII/Binary, DirectX, Milkshape3D, Orge Binary, Geomview OFF (ascii), Collada 1.4, OVB, DXF, dotXSI, Stooge, 3DS, SBM (native XNormal format), OBJ, OpenCTM, ASE, PLY, LWO, Modo.

 

@@minilogoguy18 - did you use XNormal (and dotXSI files) for your AT-ST normal maps?  Or did @@AshuraDX bake those using Substance Tools?

 

I also have the source files for the Maya 8.5 dotXSI exporter... which could be updated to support newer versions of Maya.  Blender has a dotXSI exporter in v2.42a, 2.45, 2.46) ...and I have the XSI FTK/SDK that anyone could use-- if they need it to update the Blender exporters for newer versions of Blender (@@mrwonko).

[minilogoguy18]

Ashura did all the work with the AT-ST maps in substance designer if I remember right. He contacted me the other day stating that he was going to go back and export all the maps needed for it to render using PBR so hopefully soon we can preview it in the DF2 renderer to see if anything different needs to be done in Softimage but it's unlikely.

[Archangel35757]

So I have submitted XNormal version 3.17.16 (and its SDK) to the Files > Utilities section.  Version 3.17.16 was the last version to support x86 apps and provide x86 plugins for Max7-2013 and Maya 8.5-2013.  Newer version is 64-bit only.  Also, 3.17.16 is the last version to support the dotXSI file format.  If you needed to use XNormal's .SBM mesh format, I'm pretty sure that the 3.19.2 64-bit 3ds Max and Maya .SBM exporter plugin's mesh output will still work for importing with 3.17.16.

[AshuraDX]

I for one don't even use Xnormal. I like to keep everything nice and tidy in one software. I bake and texture in Substance Painter and if required I transport those baked maps into Substance Designer to process them, which I usually only do when I used a skewmesh for baking.

 

I guess could move my worldspace normal maps into Xnormal and convert them to tangentspace maps there - which should get my work in sync, unless I'm missing something, right @@Almightygir?

 

@@minilogoguy18 It's not just a matter of reexporting. I have to retexture your ST entirely. I might create a proper Highpoly this time and update the UVs for the lowpoly.

[Almightygir]

Way to skip over my two posts....

 

 

No, xNormal doesn not support GLM but someone could make a plugin for it.

 

Sorry man, what an asshole.

 

Unfortunately time is the issue for me or i'd jump in and help. I couldn't commit right now as i'm in the middle of doing a masters degree, along with a ton of freelance work. I do wonder though, if Xycaleth has written an FBX>GLM converter, could that in some way be integrated directly into the renderer? So it does an "on the fly" conversion from FBX to GLM at load time. That would likely give you finer control over the final tangents of the GLM file as well, since you can rip them straight from the FBX.

 

As for any kind of 3ds max plugin, i think Archangel is on to something, just the wrong way round...

 

xNormal has exporter plugins that support 3dsMax, Photoshop, and Maya that exports XNormal's own mesh format (.SBM).  The older version of xNormal (v3.17.16 ...no longer available to download from xNormal.net) supports older versions of 3ds Max (Max7-2013) and Maya (8.5-2013). I will upload it to Utilities shortly.  XNormal also supports the dotXSI file format (...but it doesn't like mesh objects without texture coordinates-- meaning you must do an ExportSelected from 3ds Max and omit the bolts/tags and Stupidtriangle_off).

 

@@Almightygir, @@Psyk0Sith  - since XNormal directly supports importing dotXSI mesh files, and we export dotXSI files to be compiled into Ghoul2 models using Carcass... I would recommend that we create the normal maps using the exported High-/Low-Poly meshes in dotXSI format and import the dotXSI files into XNormal for normal map baking... it has options to use exported normals (as written in the dotXSI file).  Seems like the best option since Carcass compiles all the dotXSI files into Ghoul2 GLM/GLA, yes (...at least for 3ds Max, Softimage, Maya workflows)?

 

 

This is probably the best solution to use. And rather than what DT suggested, of writing a 3ds max tangent basis for xNormal, just use the mikktspace plugin that xNormal uses. There is another plugin option that will need to be enabled (trying to remember where it is, but i'm pretty sure it's in the tangent space calculator, and it says something like "calculate tangents and binormals" or something).

[Almightygir]

I for one don't even use Xnormal. I like to keep everything nice and tidy in one software. I bake and texture in Substance Painter and if required I transport those baked maps into Substance Designer to process them, which I usually only do when I used a skewmesh for baking.

 

I guess could move my worldspace normal maps into Xnormal and convert them to tangentspace maps there - which should get my work in sync, unless I'm missing something, right @@Almightygir?

 

@@minilogoguy18 It's not just a matter of reexporting. I have to retexture your ST entirely. I might create a proper Highpoly this time and update the UVs for the lowpoly.

 

it miiiight work. except painter bakes worldspace normals per vertex on the low poly, it doesn't do a high > low worldspace map, which is totally lame and i've complained to Nicolas Wirrman (lead designer for SP) many times about it.

[Xycaleth]

I would recommend against using FBX as a format that the renderer uses directly. FBX is designed as an interchange format i.e. An intermediate format for ease (certainly not speed) of conversion between formats. I'd imagine it to be quite a lot slower to load as well.

[Almightygir]

Yeah, i'm pretty sure UE4 does an internal conversion after the FBX has been imported into the engine, because at run-time, FBX is a dick.

 

edit: This is what we did at Marmoset btw... in fact we did it for all import formats. We had our own internal mesh format that we converted everything to.

[Archangel35757]

@@Almightygir - why use the .SBM format over importing the dotXSI file into XNormal and then using mikktspace? Carcass takes the dotXSI files and compiles the GLM. Since we export the models to dotXSI anyways isn't that the best? I guess we can do some comparison test with both formats.

 

XNormal 3.17.16 is uploaded and awaiting approval.

[Psyk0Sith]

How much damage happens once the XSI has been fed to carcass is the real question, if it breaks the sync there then the xnormal solution goes right out the window.

[Archangel35757]

How much damage happens once the XSI has been fed to carcass is the real question, if it breaks the sync there then the xnormal solution goes right out the window.

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.

 

We will just have to do some test cases and see. Perhaps you can use your new Gorc mesh for this?

[minilogoguy18]

Have you tested a 3DS Max generated dotXSI against a dotXSI file that came from Softimage to see just how accurate everything is?

 

@@Almightygir could you please summarize the workflow that you'd best recommend for all of this since it doesn't seem like we're modifying formats? It seems to me like this

 

3D package->hi/low poly dotXSI->xNormal->write low poly shaders->convert low poly to GLM->game

 

@@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.