Jump to content

Reskinning Step 1 : Duplicating game objects


Amineri

Recommended Posts

Really nice work.

 

... if an enlarged set of flags isn't possible personally I'd be happy with a generic XCOM or UN logo in place of the blank texture, which I could assign as the default to the other countries that have strat game flags but not tactical game ones.

Hold it right there -- am i reading about some "Addressable Place-Holder" gimmick to define what your cited "Blank Texture" could also mean, JL?

 

I'm no coder, but artistically - it's very easy to start dreaming about more than just a singular UN dispatch of supplemental (PeaceKeepers if anything) Troopers coming from all over the world *AND/OR/IF/GOTO/RETURN* specific countries.

 

And, since DGC already has a bunch of custom weight values to control odd percentages... enjoy the nightmare this implicates - too!

:ninja:

Edited by Zyxpsilon
Link to comment
Share on other sites

  • Replies 90
  • Created
  • Last Reply

Top Posters In This Topic

I thought the issue with the back flag textures was that they appeared in a bunch of files instead of just one, making it prohibitively complicated to swap out via non-texmod methods? (Or maybe that's what you are trying to address) ... if an enlarged set of flags isn't possible personally I'd be happy with a generic XCOM or UN logo in place of the blank texture, which I could assign as the default to the other countries that have strat game flags but not tactical game ones.

 

EDIT (Rather than fill up thread by veering away from main topic): Yep, I understand changing those flag textures would require adding something like 30+ files to the Long War download, and it's just not worth that degree of trouble.

 

To change too many files is just a little complication as long as the same data are patched into each file.

 

If you know a game Star Wars: Knight of the Old Republic, it has Override folder and if a texture is placed in it, the texture changes everywhere. Modding made easy apart from what we have to do to change a texture :smile:

 

Every armor and every deco has to be patched in two cases:

  • Case 1: generic XCOM or UN logo - updated texture (possible)
  • Case 2: enlarged set of flags - updated 3D model's UV coordinates (not so possible now)

I should have few free days now so I can see to case 1. There is one black flag, that may be your placeholder Zyxpsilon.

 

What I'd like is:

  • Case 3: call new texture placed in new package via XComgame.XComHumanPawn.UpdateFlagMaterial function.
MIC.SetTextureParameterValue('FlagTex', Texture2D'GEN_MaterialParents.Textures.Flags_DIF');

Seems like good solution, because there could be added many flags (like all countries). There would be 1 new file, and DefaultContent.ini and XComGame.upk altered. And textures could be changed via country tag and all UVs defined in DefaultContent.ini.

// UpdateFlagMaterial
if (Country == USA) {
    Texture = Flags01_DIF
}
if (Country == Whatever) {
    Texture = FlagsXX_DIF
}

// DefaultContent.ini
Flags=(Country=eCountry_USA, U=0.0, V=0.0)
Flags=(Country=eCountry_Whatever, U=0.0, V=0.0)

But I am unable to target different texture in the same package. Maybe some more experienced coder could look into the matter.

Edited by Drakous79
Link to comment
Share on other sites

I'm certainly in favor of #3 for Long War to whatever degree of improvements are possible. I'm going to pass on #1 or #2 because they will bloat the installer too much for what we gain. Perhaps Amineri will ring in here on how to handle #3. :smile:

 

We'll also look at textures for our two MEC lasers (which borrow railgun and particle cannon models), the SHIV Superheavy Pulser (and possibly Sentry Gun -- can't recall if that texture is unique or not), the reflex cannon (alloy cannon), and scatter blaster (scatter laser). There are potentially a lot more, but I don't think we have the moxie to set up an art department right now.

Edited by johnnylump
Link to comment
Share on other sites

So far one successful step done:

// XComHumanPawn.UpdateFlagMaterial
Flag = Texture2D(FindObject("Deco_Kevlar0_MOD.Textures.Deco_Kevlar0_SPC", class'Texture2D'));
MIC.SetTextureParameterValue('FlagTex', Flag);

Targeted normal texture in the same package.

Link to comment
Share on other sites

Now I am excited.

 

Edit DefaultContent.ini, find this section and add our new package:

[Content.MapContent]
Map=$ALL
Package=UICollection_Common
Package=Weapon_MEC_Lasegun

This will show new Lasegun texture in barracks!

 

Aaand with this in UpdateFlagMaterial:

Flag = Texture2D(FindObject("MECRailgun.Textures.MECLasegun_DIF", class'Texture2D'));
MIC.SetTextureParameterValue('FlagTex', Flag);

Lasegun texture from different package instead of normal flag texture.

Link to comment
Share on other sites

Very interesting thought, I was just thinking that perhaps this dynamic loading could (at times) utilize textures from different packages. The way that Firaxis duplicated the flag texture across all 30-odd armor models does kind of seem like inefficient programming.

 

I dug into Soldier_MaleKevlar_SF.upk (and using http://udn.epicgames.com/Three/MaterialsCompendium.html as a reference), I found that in the CHH_Flags parent material :

    begin object name=MaterialExpressionTextureSampleParameter2D_1 class=MaterialExpressionTextureSampleParameter2D
        ParameterName=FlagTex
        ExpressionGUID=(A=571249591,B=1092305488,C=728395679,D=-1994341701)
        Texture=Texture2D'GEN_MaterialParents.Textures.Flags_DIF'
        Coordinates=(Expression=none)
        Material=Material'GEN_MaterialParents.Master_Materials.CHH_Flags'
    object end

This adds the Flags_DIF Texture2D (which is no different structurally than all of the UI 2D textures we've already been adding for to Long War) as a MaterialExpressionTextureSampleParameter2D class object to the material.

 

From the UDK manual page : http://udn.epicgames.com/Three/MaterialsCompendium.html#TextureSampleParameter2D :

 

The TextureSampleParameter2D expression is identical to the TextureSample except that it is a parameter that can be modified in instances of the material and through code.

and through code. This means that it should be possible to change the texture to any Texture2D that has been loaded. If I'm reading this correctly, then the Texture2D need not reside in the in the soldier armor package, but could be loaded/configured separately. If it works, it could allow complete control of the flag textures used.

 

Looking at some example code from UIScreen.GetImageScale an imagepath string is converted to a Texture2D object using code such as :

    local Texture2D t2Image;

    strImage -= "img:///";
    t2Image = Texture2D(FindObject(strImage, class'Texture2D'));
    if(!WorldInfo.IsConsoleBuild())
    {
        if(t2Image == none)
        {
            t2Image = Texture2D(XComContentManager(class'Engine'.static.GetEngine().GetContentManager()).LoadObjectFromContentPackage(strImage));
        }
    }

I believe the FindObject command will work for any Texture2D image that is already loaded. If that fails, then on non-Consoles, it's possible to try and force-load the image with the second command (Console cooking requires SeekFree packages, unlike PC cooking). In general, the FindObject should be sufficient to return a given Texture2D based on its stringPath.

 

----------------

 

This is the same thing you've shows in your second example -- setting a flag texture using a texture from a separate package. In theory this means we should be able to directly reference textures cooked by UDK without having to do a bunch of hex-level editing. The primary issue to be worked around is that if the textures is part of TEXTUREGROUP_Character (for armors) or TEXTUREGROUP_Weapon (for weapons). This makes UDK generate mipmaps and multiple resolutions of the original texture, placing the higher res versions in a tfc file (which potentially also has a bunch of other texture files).

 

As a quick-test, the same thing as was done for UI elements in Long War could be done -- simply use TEXTUREGROUP_UI, which prevents any mipmaps from being created, resulting in a single copy of the full-resolution texture stored within the package itself. No tfc file is created in that case. This is much less efficient, and will result in slightly lower rendering speed since the full resolution texture would always be used, but would certainly work as an initial test.

Link to comment
Share on other sites

You can use DynamicLoadObject to load object into memory.

 

I don't think Firaxis programmers duplicated textures intentionally: it's just the way UE works. When cooking a package, UDK tries to put every referenced object into it. When game engine loads the packages, it loads only the objects, which aren't loaded already. It's made this way to speed up loading process.

 

In fact, if you look at the UDK naming conventions inside XCOM packages, you'll see that there were actually more uncooked packages, which then got merged into one seek free package. Look at the variables of Package type inside NameTable.

 

I think, they had a different packages for images, textures and sounds (resources) and referenced those from inside an XCOM specific packages (like sound banks, for example). And then it all got cooked together to optimize loading speed.

Link to comment
Share on other sites

I've verified that I can load a TEXTUREGROUP_UI image from our UDK-created LongWar.upk (that only contains Texture2D objects), by using the single line :

MIC.SetTextureParameterValue(name("FlagTex"), Texture2D(FindObject("LongWar.InventoryImages.Inv_RocketShredder", class'Texture2D')));

in XComHumanPawn.UpdateFlagMaterial. Instead of adding in the 'FlagTex' name to the XComGame.upk namelist, I simply used a StringToName cast (38 60) to dynamically create the name at run-time. For this test example I simply hard-coded a particular inventory image path into the function, but eventually the goal would be to use the m_kAppearance.iFlag value to retrieve a configure flag texture (which would need to be 256x128 resolution in order to match the UV subsection from the full flag texture).

 

The hex for the above line :

//MIC.SetTextureParameterValue(name("FlagTex"), Texture2D(FindObject("LongWar.InventoryImages.Inv_RocketShredder", class'Texture2D')))
19 00 24 4F 00 00 5D 00 00 00 00 00 00 1B 52 6F 00 00 00 00 00 00 38 60 1F 46 6C 61 67 54 65 78 00 2E 81 FD FF FF 1C 9C FC FF FF 1F 4C 6F 6E 67 57 61 72 2E 49 6E 76 65 6E 74 6F 72 79 49 6D 61 67 65 73 2E 49 6E 76 5F 52 6F 63 6B 65 74 53 68 72 65 64 64 65 72 00 20 81 FD FF FF 16 16 

Again, this isn't very efficient in terms of rendering, because the full-size texture is always being used. However it's a pretty simple way to use UDK to create textures that can be inserted, without having to muck about with a tfc.

Link to comment
Share on other sites

Update :

 

I created a new special purpose flag texture and loaded it into our LongWar.upk, and configured it to load via :

//MIC.SetTextureParameterValue(name("FlagTex"), Texture2D(FindObject("LongWar.Flags.Russia_Flag_DIF", class'Texture2D')))
19 00 24 4F 00 00 50 00 00 00 00 00 00 1B 52 6F 00 00 00 00 00 00 38 60 1F 46 6C 61 67 54 65 78 00 2E 81 FD FF FF 1C 9C FC FF FF 1F 4C 6F 6E 67 57 61 72 2E 46 6C 61 67 73 2E 52 75 73 73 69 61 5F 46 6C 61 67 5F 44 49 46 00 20 81 FD FF FF 16 16 

However, I discovered that even if the flag texture size is 256x128 (the size of one of the 32 sub-flag textures selected via UV config), the material still selects the upper 1/8 / left 1/4 (based on default UV setting). Using a 256x128 pixel flag results in a scaled up left-corner of the flag instead of the full flag being used.

 

However, when I embedded the single flag texture within a larger 1024x1024 texture, it displayed normally. For flags, this means that effectively it's going to be easiest to continue packing 32 flags into a single 1024x1024 texture and use UV offsets. However, we can now swap between 2 or more such flag textures, allowing 64, 96, 128 or more flags to be defined.

 

Also, within UDK Texture2D properties it's possible to set the LOD Group to "Character", but further down set Mip Gen Settings to "NoMipMaps" will prevent mip maps from being generated. This is an alternative to setting LOD Group to "UI".

Link to comment
Share on other sites

Good job :smile:

 

StringToName cast is very nice way how to do it.

 

Consideing tfc, if there are 10 new textures (320 flags) for an example, correcting 40 offsets for higher res images is still feasible.

 

I've tried DynamicLoadObject, but had to have something wrong, because the game freezed. I feeded the function with a string.

// UISaveGame.ImageCheck
mapImage = class'UIUtilities'.static.GetMapImagePackagePath(name(MapName));
mapTextureTest = Texture2D(DynamicLoadObject(mapImage, class'Texture2D'));

// What I tried
Flag = Texture2D(DynamicLoadObject("MECRailgun.Textures.MECLasegun_DIF", class'Texture2D'));    
Edited by Drakous79
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...