Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrating to new (>2.79) versions of Blender (and improving workflow) #986

Open
dorkster opened this issue Jan 13, 2025 · 0 comments
Open
Assignees

Comments

@dorkster
Copy link
Collaborator

dorkster commented Jan 13, 2025

1.) Migration

I think it's finally time to address this. The Blender files in the art_src are not fully compatible with recent versions of Blender. I've been telling newcomers that Blender 2.79 is needed to work with these files, but this is problematic for a few reasons:

  • Difficulty obtaining/installing 2.79. Most Linux distros are only packaging more recent versions of Blender.
  • Trouble running on modern environments. For me, Blender 2.79's GUI glitches and flickers on KDE Plasma/Wayland/nVidia until I open the user prefs window.
  • Many 3D artists are now accustomed to recent Blender version workflows. Hard to ask people to go back.

So what does this entail?:

  • Blender's internal renderer is gone. We'd have to choose one of the new ones, either EEVEE or Cycles. Performance-wise, I think EEVEE is the closest match to what we were using, so we'll probably go with that. The only downside I'm aware of is that there is no equivalent of the "shadow catcher" checkbox for our ShadowPlane. However, it can be replicated with a shader.
  • Because we're using a different renderer, the lighting is broken. We'll need to find settings that best match what we currently have. Here's roughly what I've found to look decent (though, more tweaking to be done here):
    • Multiply lamp strength by 3
    • Divide lamp color saturation by 2
  • Materials/textures need updating. I can get image texture to port over, but procedural textures will just need to be recreated or replaced. Also, for some image textures, the brightness/gamma seems off? I had to darken the texture of smaller tiles to get it to fit with the other tiles under the same lighting conditions.

2.) Workflow

This would also be a good time to review the workflow for getting Blender files into the format that the game can use. I'm working to have Python scripts, some embedded and some external, that:

  • Render all the individual "frames" (we already have this, for the most part)
  • Place all the frames on to a single sprite sheet
  • Create the Flare-specific text files (e.g. animation and tileset definitions)
  • Directory structure will be set up so that it can be easily copied to a mod

One of the bigger changes I want to do is with the player models. Right now, each piece of equipment is a separate file. Instead of that, I want to have a single file for each base (male or female), and use collections to group the pieces. I've already set up my script so that it can iterate over these, toggle the appropriate masks, and render all the sets. This will make it much easier to change or add player animations, since there's now only one rig for each base model.

3.) Time to go "HD"?

Why not tackle #209 and #791 while we're here? As long as the scripts are written well enough, it should be easy to jump to a higher output resolution. Right now, I'm testing 2X scale. Here's a before/after:

Image
Image

4.) My Goals

I'm setting a goal for myself to get this done before the end of the year. It'll probably be after the release of v1.15. In order to not totally break existing mods, the "HD" / 2X graphics mods (plural, because one for fantasycore and one for empyrean_campaign) will be shipped alongside the 1X graphics (which will be re-rendered so that the lighting matches).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant