code FEATURE: OpenGL 3 Renderer

[Archangel35757]

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

[DT.]

Because we are reliant on .XSI for this game, I vote we modify carcass to read tangent data from .XSI and output it into a .GTB file. This is by far the easiest route.

 

The FBX to GLM converter isn't finished, whereas carcass is.

[Archangel35757]

Because we are reliant on .XSI for this game, I vote we modify carcass to read tangent data from .XSI and output it into a .GTB file. This is by far the easiest route.

The FBX to GLM converter isn't finished, whereas carcass is.

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?

[UniqueOne]

The answer to the format seems pretty simple to me, if you don't want a new model format, but you could have a new extension like "modelname.glx" when rend2 goes to load a glm with the extension ".glx" load the tangents instead of generating them. It could search for .glx then fall back to .glm when not found (like is done with image loading).

 

 

The questions I have, though, are:

 

1. Will these baked tangents become meaningless if you add tesselation/displacement (which I assume you are going to want, if you want > HL2 rendering)? Since the surfaces all get changed.

 

2. I know from experience that as soon as you enable rend2 features, your FPS is going to drop to hell. I suggest you move to deferred lighting now. Do calculation on final screen pixels, not all the extra stuff it stomps over during render... or get occlusion culling working - something I have not been able to make work. (also warzone has a mini lightall glsl called shadowpass that it uses for depth and shadow renders, look at it, switch to it during those passes and you will gain a lot of FPS as the scene gets more complex).

 

3. What about maps? What's the point in having crazy detailed models when the maps themselves are not detailed. If the model format is going to get this sort of update, then the map format needs a massive update or it just wont look right.

 

4. Have any of the other projects around, that are based on rend2 or xreal, added a newer model format with tangents (new doom/Q4/whatever formats)? Maybe converting skeletal animations data is easier then changing glm - and you might get access to better 3d tools/exporters?

 

 

I am all for updating anything in the engine and renderer, its time we moved into this centry, something I've been trying to do alone now for the last 3/4 years with no opengl experience at all before starting.

 

I do wonder, however, if worrying about tangents on one model format is like building the top of the sky scraper first. Maybe, just maybe, it would be better to just make the current tangent generator code a little better in the renderer, and come back to this later on?

 

All that said, I like what you guys are doing here. Makes me happy to see others seriously working on the renderer.

[Archangel35757]

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

[UniqueOne]

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

 

It seems to me that if 3d soft can generate tangents, then why can't you do the same in the renderer code (surely there is an opensource engine that has code already to do this), just make the current method better? Then the new system could be used for all game objects, so that they all match. If tangents on walls look different to tangents on md3's which look different to tangents on glm's, what is gained? I think you guys need to look at the bigger picture and create 1 good system for everything.

[Archangel35757]

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

[UniqueOne]

@@UniqueOne - go back and start reading from page 10.

 

If you have source code to FBX2GLM, could that code be added into the GLM loading code and load FBX itself? Since from what your saying, it has the original tangent info. Still not sure what you would do with MD3 and BSP though...

[Archangel35757]

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

[DT.]

It's either someone codes FBX support to carcass, or we stick to .XSI all the way - including for xnormal. Using all these different formats isn't a good idea. Stick to one "middle" format.

[Archangel35757]

It's either someone codes FBX support to carcass, or we stick to .XSI all the way - including for xnormal. Using all these different formats isn't a good idea. Stick to one "middle" format.

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.

Edited February 28, 2017 by Archangel35757

[DT.]

The FBX to GLM converter isn't complete, requires more work to be complete.

 

Carcass is complete.

 

Really a no-brainer to use carcass to generate a GTB because, less work to be done.

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

[DT.]

How about this:

 

Export to XSI for carcass to compile to GLM as usual, then run that GLM through a modified FBX2GLM (could be called GLM2GTB) to create this .GTB file.

 

This probably has already been mentioned. Been a long day with some weird shit happening.

[Almightygir]

my only problem with sticking to .xsi as a format, is that softimage is now non-existent and will be harder and harder to get hold of as various torrenters stop seeding it.

 

i thought about this some more last night, you're much better off supporting any form of FBX > GLM/GL2 worflow. Unfortunately the support i can offer right now is limited, i'm in the middle of doing a masters degree which is sucking up all of my time. However i finish in september, and i'm more than happy to jump in and help with tools development then, maybe even see if @@Xycaleth's program can be updated to include skeletal mesh outputs? If we can reach that stage, then the entire .xsi workflow will be obsolete.

[Archangel35757]

@@Almightygir - while it is true that Softimage is dead. That's not really an issue for this community since this game can be modded using the free XSI Mod Tool 6.x/7.x (which we have from various sites).

 

@@DT85 - but it has to be the low-poly file used for the baking... as I understand it-- so either dotXSI or FBX, and not the GLM file which is not used for baking.

 

I think with my last posted suggestion both FBX and dotXSI formats for baking should be fine.

[Xycaleth]

Here's the source code for the FBX to G2 converter in case anyone was wondering:

https://github.com/xycaleth/FBX-Ghoul2-Converter

 

I can't remember where I got to. I think I had problems with normals not being written correctly..

[minilogoguy18]

I really like @@Almightygir's suggestion and I'm super stoked that he's willing to help in the near future. I wanted FBX support (or even the newer dotXSI 6+) ever since the source code for the tools had come out simply because a newer format could allow us to do so much more. It also would ensure that newer software would be able to be used to mod this old but still surprisingly popular game. Softimage isn't quite gone yet though, there are still very active communities and Autodesk still offers licenses and student licenses for v2015.

[DT.]

The reason if I remember that Xycaleth stopped with his FBX2GLM was due to Noesis being able to export GLM. Perhaps someone can try and contact Rich, the creator of Noesis to possibly add support for writing a GTB? His program can already parse FBX into GLM, but has issues with LODs if I remember correctly. I tried contacting him months ago about it, but no reply.

 

Just another option.

 

 

Personally, I'd rather see carcass reading FBX and outputting a GTB. Get everything all in the same program.

[Archangel35757]

While FBX is the current intermediate file format... it doesn't bring anything new to this game that you cannot already do today with XSI. @@AshuraDX used OBJ for his clone and yet the dotXSI/GLM result looks great.

Edited March 1, 2017 by Archangel35757

[AshuraDX]

While FBX is the current intermediate file format... it doesn't bring anything new to this game that you cannot already do today with FBX. @@AshuraDX most likely used it for his clone and yet the dotXSI/GLM result looks great.

I used .obj!

Had some trouble with getting .fbx loaded properly in Substance before, so at some point I just switched to .obj.

[Archangel35757]

Good to know! Forget FBX then...

 

Based on some quick googling... the feature to export tangents & binormals in an FBX file (added around SDK 2010.2/2011???) had issues in early versions when this was added. And was still broken in SDK 2012/2013 versions. Seems to have been finally fixed in FBX SDK 2014.2???

 

Anyways... the old Crosswalk FBX exporter for XSI ModTool 6.x does not have a feature to export out tangents and binormals... neither do older 3dsMax FBX exporters (that I could see). If XSIModTool 7.x doesn't have a feature to export tangents and binormals then this whole FBX discussion is moot.

Edited February 28, 2017 by Archangel35757

[minilogoguy18]

The reason is dotXSI is super old and going away, the only reason why it even exists still is because of you, no one else is using it. FBX support will ensure software will be able to be used to mod JA in the future. If you lose interest tomorrow it's all over for future Max users and on top of that Maya, which is the #1 software hands down being used in 3D today can't even be used for JA unless you get a SUPER old version.

 

@@DT85 should probably just decide hands down what he thinks is best for the mod, I'm OK with putting FBX through carcass.

[Archangel35757]

@@minilogoguy18 - This community has everything it needs to support dotXSI indefinitely. I don't see any Maya users here... and if there are, I have the resources to update the Maya dotXSI exporters-- there's no demand presently.

 

Secondly, older FBX exporters for older versions of 3ds Max and XSI Mod Tool 6.x DO NOT have an FBX export option to output tangents and binormals.

 

Does XSI ModTool 7.5 support exporting FBX tangents and binormals? If not then XSI Mod Tool would no longer be a viable modding tool for an FBX pipeline.

 

Finally, (from my Google searches) there were bugs in older versions of the FBX exporters when computing tangents and binormals:

 

https://forums.autodesk.com/t5/fbx-forum/tangents-amp-binormals-issues-fbx-2013-2-3dsmax-and-maya-exports/td-p/4257978

 

...which seems to have had all known issues fixed by FBX SDK 2014.2; but this is a fairly new SDK and only supports back to 2012 versions of 3dsMax, Maya, etc.

 

So there is no real justification to add FBX to Carcass.

 

Santiago has agreed to add dotXSI 3.0/3.5/5.0/6.0 support back into the next release of xNormal. Until then we can use xNormal 3.17.16.

 

OBJ is an even older format (...and is the format @@AshuraDX used for his clone trooper because he said he had issues trying to use FBX in Substance Designer and gave up on it)... I don't hear you wanting to ban OBJ.

Edited March 1, 2017 by Archangel35757

[minilogoguy18]

I don't know about max but for Softimage you can install a later version of crosswalk than that what shipped with the software to update the plugins.