Quote from: Gistech on February 07, 2018, 01:47:25 PM
That's an issue with the model and not the textures. Import the model into Mod Tool then re-export it and the issue will vanish.

Any idea what exactly is at fault here? Material colour? Vertex colours? I'll try to remember to take a look at this sometime soon.

Quote from: zealot on January 30, 2018, 02:58:53 PM
What Seriously?! I'll take a look at it again and see whats wrong...

You did read my post right? Because it sounds to me like you may not have set the platform switch correctly.

In addition to what Gistech said (the model may just need some manual touchups, although I wouldn't expect it to not show up at all). You should make sure you've set the '-platform' and '-version' switches correctly. With them set incorrectly you can get bad output for some files.

Huh, interesting to know!

If you have the game files, swbf-unmunge can extract models from the PS2 version but not textures. You can use that to get the model at least.

Well this is embarrassing, the event callback was supposed to be capturing the name of the class to set the properties of. I refactored this a couple times while settling on a design so that'll be how I missed it. Still that is a pretty big flaw to miss.

I've updated a the gist with a fix and you can see the difference here. Thanks for making me catch that, I prefer to not leave horribly broken code floating around.

Anyway yes it updates classes, not instances of a class. This is because my understanding there are certain properties (GeometryName) that can only be updated at respawn. This also does mean that you're limited to using properties that only update with respawn. Perhaps I should've clarified this aspect of the design in the documentation.

Although it could be extended quite easily to also support properties that don't need a respawn to update. If you (or anyone else) is interested in that just let me know.

If it is model-edit causing it I can only take guesses as to what is causing it. Since most people report that it works perfectly. One guess would be the edit's it makes to the segment chunks, if I recall correctly editing them didn't actually affect the game's willingness to the draw them, so it is possible that is what is causing it. (This is backed up by the screenshots which seem to suggest individual segments of the model are failing to be drawn.)

I have posted a new version of the tool with the segment edits removed. I haven't tested it but it should continue to work same as before. (You can find it on the GitHub page.) Let me know how it goes.

The documentation that comes with the modtools is a great place to start. It's all in the 'documentation' folder of the modtools, the intuitively named 'Getting Started.doc' is probably the best place to start. You can also find it all online over here https://sites.google.com/site/swbf2modtoolsdocumentation/getting-started and GameToast has extensive community made resources as well over here http://gametoast.com/viewtopic.php?f=27&t=13806.

I can't remember if Visual Munge has any DRM or not, if it just asks you to point it to where you have SWBFII installed then just point it to any folder you want munged files ending up. Let me know how it goes for you.

Once you have a PC map building of some kind then check out these build scripts for the PS2 version over here http://www.gametoast.com/viewtopic.php?f=64&t=21948. I've never used them myself but they seem like exactly what you're after.

Someone flicked me a question about a skin randomizer they had found for SWBFII and how it could be expanded to support more than two skins. Having just gotten back from being away from home for a couple weeks I've taken the time to look through what they sent me and quickly make a skin randomizer that should do what they want.

After a player (or ai) spawns in as a class a new skin is randomly picked for that class for the next time that class spawns. Usage can look as simple as this.

EnableRandomizedSkins{
   cis_inf_sbdroid = {
      {
         { property = "GeometryName", skin = "name of a model" },
         { property = "GeometryLowRes", skin = "name of a low res model" }
      },
   },

   rep_inf_trooper = {
      { property = "OverrideTexture", skin = "name of a texture" },
   },
}

You can find the script over here. It is documented with usage instructions and detailed comments on how the code works. However it is completely untested (hence why this isn't in Release Assets), however it should work but even if it doesn't it should still serve as a fine starting point for anyone looking to implement something like this.

Your process for using the modtools is confusing me. The only thing that would spit this back at you is the game's own normal executable (battlefrontii.exe) or the modtools debug executable (BF2_modtools.exe), which is a replacement for the normal executable that can be used to debug mods.

Can please clarify what you're trying to accomplish by launching one of these? Because aside from testing modes neither of them will help you or let you create mods.

If you need the executable you'll probably need the whole game as well, so buy it on GoG https://www.gog.com/game/star_wars_battlefront_ii?

But I'm pretty sure I've already said this but for porting maps to the PS2 you don't need the PC version of the game. You can munge maps just fine without it.

From your original message I gather you tried to run 'BF2_Modtools.exe'? That executable is a special build of the PC version of the game for debugging mods. It needs to go beside the game's normal executable to work.

It sounds like you've managed to install the modtools. But it sounds like you still need to read the documentation that comes with them. (I can't check now but I'm pretty sure what I wrote above is explained in Getting Started or something like that.) You should be able to do what you want without owning the game on PC, you just need to study how the modtools and game works a bit more. Reading through the modtools documentation would be a good place to start.

My swbf-unmunge tool can 'explode' an .lvl file into it's discrete chunks, it can then reassemble them into a working lvl file again. It will obviously take care of things like chunk size tags for you, if you want to edit .lvl files directly then that is the best way.

But as Phantom was saying using the modtools themselves is a far better option, with the right configuration they can create custom content for the console version of the game just fine. (I think on Gametoast you can find preconfigured PS2 munge scripts.)

Quote from: Ginev on December 27, 2017, 01:00:01 PM
Maybe just maybe someone...in the future...relef shder for models or atleast terrain texture?

Relief mapping requires a depth map as well as a normal map to work. And since any change I make to the normal mapping shader will affect everything in the game it would lead to everything that didn't also have a depth map attached looking not quite as good as regular normal mapping.

However that said there are some ways to potentially hack in custom material types so I will keep adding relief mapping in mind!

So I've been making thing for SWBFII. This time it is using the shader toolkit I previously and a bit of cheeky DLL hijacking (like ENB or ENB esque mods) to hook into the Direct3D 9 run time. By injecting some metadata into the compiled shaders using a modified version of the compiler I made for the toolkit I can identify and make sense of the game's rendering pipeline in code. All without ever touching the game's executable or any of the ones it shipped with. (Which means as best I can tell this is not in violation of the EULA.)

So what does it do? Well currently it does some basic things that may seem dull but still provide notable improvements to visual fidelity without (hopefully) affecting the game's or any mods art style/direction. 

• Borderless Fullscreen Windowed Operation   
• Per-Pixel Lighting for Most Things
• Per-Pixel Fog for Most Things
• Derpy Proof-of-Concept Soft Shadows

Let's go through what some of those do and look like. Ideally I would just have side by side before and after pictures but there is only so much time in a day.

If you go here you can see the soft shadows. The idea here is quite simple, soft shadows usually look nicer than hard edged stencil shadows. (Hard edged stencil shadows could of course be used to great artistic effect in a game's art style and that is a very interesting topic for another time.) In this case I am simply blurring the shadow map before it's sampled this is in no way physically correct and does cause artifacting in certain places. But more importantly than those in most cases in looks nice. Eventually I would like to see about using different techniques like depth aware blurring to boost the quality and remove some of the artifacting. (And maybe even though in some form of Ambient Occlusion as well.)

Next here we have a poor example of the per-pixel lighting. You can see how the lighting more accurately and smoothly interacts with the storm troopers armour by fading at more correct angles. A better example would be on meshes that have low-tessellation (triangle count) over a large area. In those circumstances you can clearly see individual point lights interact correctly with the surface by fading out correctly and smoothly. Shoot a bunch of lasers down a hallway or a sniper bolt at a flat wall to see this effect.

Finally for now here you can see the per-pixel fog. Now I'll level with you, this was implemented primarily out of need. I had to ditch Shader Model 2 in order to get per-pixel lighting globally enabled. This killed the fixed function fog the game used which meant I had to re-implement it in shaders myself.

While doing this I made a couple improvements because A. Why not? and B. It is was easier to. The fog is now range based which means that objects will fade based of their world position not their perspective position, which creates less visual anomalies and is also closer to how fog works. The second is that fog is calculated per-pixel which is more expensive but gives a much nicer result as individual pixels have their fog coverage determined individually based of their distance. You can see this in action in the screenshot.

Some features I would like to look at adding are...

• Soft Particles (maybe hard to integrate well into the game, but it would be really nice if they could be)
• Improved Water and (maybe) Ocean Effects
• Improved Refraction and Blur Quality
• Improved HDR Rendering (currently normal maps can have their detail washed out before they're blended with their diffuse maps, some form of improved HDR rendering could fix this)
• Order Independent Transparency (fixes things like command posts appearing behind glass)
• (maybe) Depth-of-Field
• (maybe) Other things I'm forgetting right now...

Be sure to give me your thoughts and say if you're interested in this! Or even better test it out, you'll obviously need an adequately capable GPU to run it. (If you have a DirectX 10/11 Feature Level GPU you are probably fine to give this a go.)

To install the current (early, likely unstable, don't be surprised if it crashes on you) version of it download and extract the contents of the folder below to your GameData folder. You should see dinput8.dll in the same directory as battlefrontII.exe.

Current Version (Backup your core.lvl before installing!)

The source code is of course coming soon. (That is as soon as I clean up the projects structure and write a readme.)

As a heads up, I can imagine some anti-viruses flagging this because of how it works (DLL Hijacking). It isn't, or at least it shouldn't be (if someone hijacked the web page they could trick you into downloading a version that was a virus, although that probably won't happen (but it could (although it probably won't, but still, it could))). Anyway the point is it is (probably) no more likely to be a virus than anything else you download from this site. But since it is a DLL if you're not comfortable installing that beside your game then that is highly understandable and I don't blame you for potentially giving it a pass.

I've used a Nvidia card (one of these with a custom vendor cooler for those curious) for the past three years and never had a GPU related issue (that I can remember) when running Zero Editor . So I would be inclined to instead say that with you might have issues rather than probably having them.

Although a disclaimer about possible Survivorship bias is needed from me here.