Tempust85

I just fixed it while you were posting lol. It was indeed -s needing *ratio but not cmd->x. Basically, the start scale was fine but the end scale wasn't which I believe the { -s, c, 0.0f } line is responsible for. Thanks for the help guys!

....so this?

.....AO? But then why would you be showing that off in a cubemap... Just tell me already! I must know, it's killing me!

Need moar hints!

Exactly.

That PS2 game uses a t-900 model, which pretty much has coverings all over. The original t-800 model has everything exposed, thus means more tris than this game can handle. I could barely get HL2 to load one at 9k tris. Really needs a budget of upto 15k tris to look decent. It would look like total rat shit to have nearly all pistons as alpha planes. Yet ANOTHER reason we need a fully functioning GL2 for JKA.

Hm, good point. I'll export to MD3 as it's easier to export and load in-game. They both display normal maps the same.

The fix is already coded, I just haven't checked them to see yet. So far only the fonts, HUD (not all of it yet) & crosshair have the ratio fix. I can't do anything about the menu backgrounds, I'll have to redo them as 16:9 and 4:3 res players will just have to deal with it. I've also made a setting for it in the setup menu (Set Ratio: 16:9 or 4:3) which i've made require a vid_restart to apply the change. Fonts look seriously borked without a vid_restart. I've ALSO added the 720p & 1080p widescreen resolutions to r_mode.

Added that, thanks. Rotating circle start size is a circle, but morphs into this by the end of zooming: And the green ticks still do not look right, at the bottom where they end. They clip over the blue art as you can see, but don't at a 4:3 resolution.

My test. FBX was exported with tangents and binormals checked, SBM was exported with tangent basis checked.

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.

@@ent the rotatepic2 code is different to yours. Could you please find a fix for this version? static const void *RB_RotatePic2 ( const void *data ) { const rotatePicCommand_t *cmd; shader_t *shader; cmd = (const rotatePicCommand_t *)data; // FIXME: HUGE hack if (!tr.renderFbo || backEnd.framePostProcessed) { FBO_Bind(NULL); } else { FBO_Bind(tr.renderFbo); } RB_SetGL2D(); shader = cmd->shader; if ( shader != tess.shader ) { if ( tess.numIndexes ) { RB_EndSurface(); } backEnd.currentEntity = &backEnd.entity2D; RB_BeginSurface( shader, 0, 0 ); } RB_CHECKOVERFLOW( 4, 6 ); int numVerts = tess.numVertexes; int numIndexes = tess.numIndexes; float angle = DEG2RAD( cmd->a ); float s = sinf( angle ); float c = cosf( angle ); matrix3_t m = { { c, s, 0.0f }, { -s, c, 0.0f }, { cmd->x, cmd->y, 1.0f } }; tess.numVertexes += 4; tess.numIndexes += 6; tess.indexes[ numIndexes ] = numVerts + 3; tess.indexes[ numIndexes + 1 ] = numVerts + 0; tess.indexes[ numIndexes + 2 ] = numVerts + 2; tess.indexes[ numIndexes + 3 ] = numVerts + 2; tess.indexes[ numIndexes + 4 ] = numVerts + 0; tess.indexes[ numIndexes + 5 ] = numVerts + 1; VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts ]); VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 1]); VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 2]); VectorCopy4(backEnd.color2D, tess.vertexColors[ numVerts + 3 ]); tess.xyz[ numVerts ][0] = m[0][0] * (-cmd->w * 0.5f) + m[1][0] * (-cmd->h * 0.5f) + m[2][0]; tess.xyz[ numVerts ][1] = m[0][1] * (-cmd->w * 0.5f) + m[1][1] * (-cmd->h * 0.5f) + m[2][1]; tess.xyz[ numVerts ][2] = 0; tess.texCoords[ numVerts ][0][0] = cmd->s1; tess.texCoords[ numVerts ][0][1] = cmd->t1; tess.xyz[ numVerts + 1 ][0] = m[0][0] * (cmd->w * 0.5f) + m[1][0] * (-cmd->h * 0.5f) + m[2][0]; tess.xyz[ numVerts + 1 ][1] = m[0][1] * (cmd->w * 0.5f) + m[1][1] * (-cmd->h * 0.5f) + m[2][1]; tess.xyz[ numVerts + 1 ][2] = 0; tess.texCoords[ numVerts + 1 ][0][0] = cmd->s2; tess.texCoords[ numVerts + 1 ][0][1] = cmd->t1; tess.xyz[ numVerts + 2 ][0] = m[0][0] * (cmd->w * 0.5f) + m[1][0] * (cmd->h * 0.5f) + m[2][0]; tess.xyz[ numVerts + 2 ][1] = m[0][1] * (cmd->w * 0.5f) + m[1][1] * (cmd->h * 0.5f) + m[2][1]; tess.xyz[ numVerts + 2 ][2] = 0; tess.texCoords[ numVerts + 2 ][0][0] = cmd->s2; tess.texCoords[ numVerts + 2 ][0][1] = cmd->t2; tess.xyz[ numVerts + 3 ][0] = m[0][0] * (-cmd->w * 0.5f) + m[1][0] * (cmd->h * 0.5f) + m[2][0]; tess.xyz[ numVerts + 3 ][1] = m[0][1] * (-cmd->w * 0.5f) + m[1][1] * (cmd->h * 0.5f) + m[2][1]; tess.xyz[ numVerts + 3 ][2] = 0; tess.texCoords[ numVerts + 3 ][0][0] = cmd->s1; tess.texCoords[ numVerts + 3 ][0][1] = cmd->t2; return (const void *)(cmd + 1); } I've tried adding *ratio to the every cmd->w (this looks to be the width?), but it still doesn't look right.

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.

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.

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.

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.

You can do that in the effectsEd, where you can call another effect upon effect "death", but no idea how to do that in code.

@@Psyk0Sith Here's a shader for your test box: models/players/XNbox/diffuse { { map models/players/XNbox/diffuse rgbGen lightingdiffuse } { stage normalmap map models/players/XNbox/normals normalScale 1 1 } } ONLY use the .mtr extension IF there is already a .shader of the same name. So in this case, use .shader. If the normals need to be flipped, use "normalScale". First value is red channel, second value is green channel. "1" will leave the normals 'as-is' "-1" will invert the channel You can also increase/decrease the intensity of the normals by changing the "1" to a higher or lower value.

Here's the link: https://github.com/DT85/OpenDF2/tree/rend2-sp

I'll tidy a few things up and commit the code, then post back here with a link.

Yaaaaas! Well done good sir!

@@ent Ok, it's working. Now it's just the disruptor being a pain: When it should look like this, but widescreen of course: Notice how the green ticks aren't placed properly, or the rotating blue circle. Seems like the rotate fix trap isn't doing what it should, even though I've put it in all the way into the renderer.

I may have missed one or two things, I'll have to double check again.

why stop at what I'd call "HL2 quality" when we can make an attempt at something higher? That reminds me, I'd like to see subsurface scattering at some point. I don't expect this to be worked on just yet though, we have more pressing issues like sprites, dlight stuff and weather.

How is it forcing a pipeline on the community though? This is DF2 mod, not openjk. If what we accomplish with GL2 gets ported to openjk, the community can either adopt the pipeline to have 100% proper looking assets or not. it's their choice. if they don't like it, they can stick to GL1.