Skip to content

Baldur’s Gate “True HD Edition” - How Feasible Would It Be Today?

ZorutarZorutar Member Posts: 62
edited November 3 in General Modding
Hi everyone,

I’ve been thinking about how realistic it would be to create what I would call a “True HD Edition” of Baldur’s Gate.

By “True HD Edition”, I do not mean a remake or redesign. The idea would be to preserve the original Infinity Engine experience, maps, proportions, gameplay and overall art direction as closely as possible, while bringing the visual presentation to a level that looks genuinely sharp and consistent on modern 1440p / 4K displays.

Parallel discussion on the Gibberlings3 Forums: Baldur’s Gate “True HD Edition” – How Feasible Would It Be Today?

There is also an interesting new context for this discussion. Recent reports suggest that Wizards of the Coast is working on a remake of Baldur’s Gate II, with original BG2 co-lead designer Kevin Martens reportedly involved, and that Baldur’s Gate I may receive similar treatment:

https://www.pcgamer.com/games/rpg/a-baldurs-gate-2-remake-is-apparently-in-development-with-the-original-co-lead-designer-returning

These projects have not yet been officially unveiled in detail, so we do not know what engine, ruleset or design approach they may use. But if they are full remakes, they could potentially involve rebuilt environments, new rendering technology, redesigned presentation, and perhaps gameplay or UI changes.

That raises the opposite question:

“What would the original Baldur’s Gate look like if the Infinity Engine version finally received the true HD treatment it never had?”

The aim would therefore not be to compete with a potential official remake, but to retain the original games while restoring, reconstructing or recreating their visual assets at much higher fidelity.

For short- and medium-term experimentation, the existing Enhanced Editions — running on Beamdog’s enhanced version of the original Infinity Engine — are an obvious platform, potentially extended through EEex and projects such as InfinityEngine-Enhancer. GemRB, however, may be particularly important as a longer-term open-source foundation, where the renderer, asset formats and other engine-level systems can be modified directly.

This is especially interesting because Project IE 4K is already experimenting with exactly this broader approach:

https://github.com/Goddard/Project-IE-4k

Rather than only upscaling backgrounds, it attempts to create a wider 2K/4K Infinity Engine asset pipeline, including graphics, BAM animations, UI assets, paperdolls, world maps, area geometry, cinematics and coordinate-dependent data, together with modifications to GemRB so the engine itself understands the increased scale.

That matters because a real 4x conversion is not simply a matter of making textures larger. It can also affect coordinates, movement and projectile speeds, selection circles, doors, triggers, UI positions and other engine-level assumptions.

So there appear to be two complementary technical directions worth exploring:

Enhanced Editions + EEex / InfinityEngine-Enhancer: maximum compatibility with the existing games and mod ecosystem while extending the current engine to support higher-resolution assets.

GemRB, supported by work such as Project IE 4K: a more flexible long-term open-source foundation capable of scaling both graphical assets and underlying engine systems.

Several existing projects already address different pieces of the problem:
Taken together, these projects suggest that parts of the pipeline for a “True HD Edition” may already exist independently. Some address engine-level support, others area reconstruction, environmental restoration, creature animations, UI or broader asset conversion.

Related technical research and previous community work

A considerable amount of relevant technical knowledge and previous community work has accumulated over the years, often in discussions or projects that were not specifically aimed at an HD edition.

The selection below is intentionally limited to some of the most relevant examples, particularly where they document known engine limitations, previous high-resolution experiments, asset-format constraints or technical approaches that could help avoid rediscovering the same problems from scratch.

Technical discussions and research
  • IESDP animation research
    https://www.gibberlings3.net/forums/forum/54-iesdp-updates-and-info

    Recent work by @Incrementis and others systematically documents different Infinity Engine animation types, layering, palettes, weapon overlays, translucency and animation sequences. This research could be particularly useful when defining which existing actor behaviors a future HD sprite or direct-3D system would need to preserve.

  • Near Infinity – high-resolution BAM V2 / PVRZ discussion
    https://forums.beamdog.com/discussion/30593/new-versions-of-nearinfinity-available/p45

    Recent Near Infinity work provides a particularly relevant data point for high-resolution assets. In January 2025, Pecca described using 1024-pixel BAM blocks for high-definition backgrounds, while @argent77 confirmed that BAM V2 formally supports frame sizes up to 65535 pixels per dimension and fixed an encoder issue affecting frames of 1024 pixels or more. This suggests that some apparent HD-asset limits may be tooling limitations rather than fundamental BAM V2 constraints.

  • Area creation: An overview
    https://www.gibberlings3.net/forums/topic/38344-area-creation-an-overview

    A detailed overview by @Acifer of how Infinity Engine areas are structured and produced, including ARE, WED, TIS/PVRZ, search maps, light maps, height maps, walls, doors, overlays and other components. This is useful context for understanding why an HD area is much more than a single background image.

  • PVRZ / TIS conversion, water-layer and seam issues
    Water-layer discussion: https://www.gibberlings3.net/forums/topic/37063-water-layer-corruption-in-pvrztis-file
    Door / animation seams: https://www.gibberlings3.net/forums/topic/35260-area-dooranimation-graphic-black-lineseam-issues

    Two practical investigations into problems that can occur when area artwork passes through the EE PVRZ/TIS pipeline. Together they document water-layer corruption, graphical seams and color bleeding involving compression, tile packing, doors, overlays, animations and WED data. They provide a useful reminder that reconstructing an HD area may still require substantial technical and manual cleanup even when the underlying artwork itself is correct.

  • BG2 graphics upscale brainstorm
    https://www.gibberlings3.net/forums/topic/30965-bg2-graphics-upscale-brainstorm

    An important earlier discussion covering TIS/WED/ARE scaling, absolute coordinates, BAMs, scripts, animation interpolation, engine modification and GemRB. It eventually developed into the work now represented by Project IE 4K.

  • Upscaling Infinity Engine Maps with AI
    https://forums.beamdog.com/discussion/73868/upscaling-infinity-engine-maps-with-ai

    An early practical attempt to apply AI reconstruction to Infinity Engine graphics. During the 2018–2019 experiments, backgrounds and BAM animation frames were upscaled and reintroduced into the game at substantially higher resolutions. The work exposed exactly the broader scaling problem faced by a true HD conversion: increasing asset resolution also affects area layers, positioning, UI placement, world scale and other coordinate-dependent systems.

  • GemRB bugs, issues and problems with mods and mega-mod setups
    https://www.gibberlings3.net/forums/topic/29884-gemrb-bugs-issues-and-problems-with-mods-and-mega-mod-setups

    A particularly useful historical compatibility thread testing GemRB against real heavily modded installations containing NPC, quest, graphical and gameplay mods. It illustrates why preserving compatibility with more than twenty years of emergent Infinity Engine / WeiDU behavior may be just as important as modernizing the renderer itself.

  • What stops Beamdog from remastering the sprites?
    https://forums.beamdog.com/discussion/22517/what-stops-beamdog-from-remastering-the-sprites

    One of the most relevant historical discussions for the actor side of an HD edition. Beamdog developer Dee explains that the original sprites had been rendered from 3D source models, but those models were no longer available. Higher-resolution replacements would therefore have required either recreating the original models from scratch or manually reworking enormous numbers of animation frames, together with engine changes allowing higher-resolution sprites to retain their original physical size in the game world.

  • Flipbook animation transparency
    https://forums.beamdog.com/discussion/245/flipbook-animation-transparency

    An early Beamdog developer discussion about alpha transparency, BAM limitations, animation layering and possible future graphics formats. Trent Oster explicitly discusses a longer-term approach involving 32-bit PNG source images and a BAM 2.0-style pipeline. It is a useful historical precedent showing that richer sprite and effect representation was already recognized as an engine-level issue during the development of BG.

  • The Infinity Engine Rendering System
    https://www.gibberlings3.net/forums/topic/19345-the-infinity-engine-rendering-system

    An older GemRB discussion examining how the Infinity Engine combines TIS/WED backgrounds, overlays, walls, doors, creatures and equipment layers during rendering. Although old, it is useful background for understanding the rendering semantics that any modern replacement still needs to preserve.

Related projects and technical precedents

One of Beamdog’s major limitations was that much of the original high-resolution/source artwork — and, critically, many of the original 3D source models used to render character and monster sprites — was no longer available.

Beamdog developers explained that the original sprites had been produced by rendering 3D models into animation frames. Without those source models, creating higher-resolution replacements would have required either reconstructing the models from scratch or manually reworking enormous numbers of individual frames, together with engine changes allowing higher-resolution sprites to retain their original physical size in the game world.

Today, however, the technical landscape is substantially different. We have much better super-resolution and image-to-image reconstruction, digital repainting and restoration tools, modern 3D software, increasingly capable automation, and more flexible engine-level approaches through EEex / InfinityEngine-Enhancer and GemRB.

A rough definition of a “True HD Edition” could include:
  • 4x or similar high-quality reconstruction/upscaling of area backgrounds
  • manual cleanup of reconstruction artifacts
  • HD night maps, lighting and environmental effects
  • higher-resolution UI assets
  • HD portraits and paperdolls
  • improved spell and visual effects
  • improved world maps and cinematics
  • higher-resolution character and monster sprites, or potentially a modernized actor rendering pipeline
  • compatibility with BG1EE, BG2EE, and ideally EET
The backgrounds already seem increasingly solvable through projects such as InfinityEngine-Enhancer + BGEE Graphics Enhanced and BGGO, while the BG2 HD Visual Project and earlier AI Denoised Areas work demonstrate additional approaches to reconstructing and improving original area artwork. Infinity UI++ demonstrates extensive UI flexibility.

The biggest remaining challenge may therefore be artistic reconstruction and art direction — particularly character and monster animations.

This is essentially the same bottleneck Beamdog identified more than a decade ago, but the range of possible solutions is considerably broader today.

Since many of the original 3D source models are no longer available, a modern reconstruction effort could potentially:
  1. upscale and restore the existing BAM sprites as a conservative baseline,
  2. reconstruct individual frames using AI-assisted workflows combined with manual art direction and cleanup,
  3. recreate the original animation sets with new 3D models and render them back into Infinity Engine-style sprites, potentially using tools such as IE AutoSpriter,
  4. eventually allow an open engine such as GemRB to render reconstructed 3D actors directly while preserving the original camera, scale, lighting and overall visual language,
  5. use different approaches for different animation families rather than forcing a single solution across every asset,
  6. or address part of the problem differently at the engine level.
Project IE 4K suggests that scaling and rebuilding BAM assets at higher resolutions is technically possible, while the BG2 HD Visual Project already demonstrates higher-resolution creature sprites in BG2EE and IE AutoSpriter provides a practical bridge between modern 3D modelling tools and the existing Infinity Engine animation system.

There is obviously a major difference between simply increasing sprite resolution and reconstructing convincing new detail while retaining the original visual style.

And that leads to the main questions:

How large would such a project actually be?

Could a small, experienced team of perhaps 3–5 people create a convincing “True HD Edition” over a few years by building on existing work, or would it realistically require a much larger effort?

Where should the line be drawn between restoration, reconstruction and recreation?

Could projects such as InfinityEngine-Enhancer + BGEE Graphics Enhanced, BGGO, BG2 HD Visual Project, AI Denoised Areas, Project IE 4K, IE AutoSpriter and Infinity UI++ eventually converge — or collectively provide enough reusable techniques and lessons — to form the basis of something approaching a genuine “True HD Edition” of Baldur’s Gate, even without the original BioWare source assets?

And could the Enhanced Editions + EEex / InfinityEngine-Enhancer continue to serve as a practical environment for experimentation and compatibility today, while GemRB, supported by work such as Project IE 4K, gradually develops into a more open and future-proof foundation for modern rendering and asset formats?

I’d be very interested to hear your thoughts.
Post edited by Zorutar on

Comments

  • ZorutarZorutar Member Posts: 62
    Small update to the main post:

    I’ve added several more projects and approaches that are relevant to the broader “True HD Edition” idea, including additional work on HD backgrounds, AI-assisted area reconstruction, higher-resolution creature sprites, engine-side scaling and related asset pipelines.

    The more I research this, the more it seems that quite a few important pieces already exist independently across different projects and modding communities.

    I’m trying to keep the opening post updated as a central overview of the existing work, technical approaches and remaining challenges, so anyone interested in the idea can see what has already been attempted and where the biggest gaps still are.

    If anyone knows of other relevant projects, experiments, tools or older discussions that I may have missed, please feel free to share them here.

    And of course, anyone interested in the broader technical feasibility of a faithful Baldur’s Gate HD remaster is very welcome to join the discussion.
  • SourSour Member Posts: 193
    My opinion is that most of the approaches provide an improvement or the capability of one but it's hard to say what the best approach would be.

    AI denoised areas actually alters the backdrops with generative AI. It's not the same as a 1 for 1 upscale with denoising. I would know because I started a similar project on this website a long time ago before any of this was created. I abandoned the project when Nvidia released DLDSR in it's control panel for owners of their Nvidia graphics cards. DLDSR is a Super Resolution down sampling method that denoises the image and anti aliases the final render. I've been using this on the infinity engine games for a long time now.

    If infinity enhancer used the BGGO backdrops as it's original source then I would be more inclined to use it but currently I find that BGGO combined with DLDSR is the best overall option currently available. I combine that with Infinity UI, icon remasters and 4x frame generation from lossless scaling.

    I've seen generative AI examples on the steam community posts that transform the horrible character sprites into works of art. If someone were to create those sprites and animate them at 30FPS or more then it would be amazing. I'm not sure if GEMRB would be required to do something like that or not. I simply haven't looked into it. I didn't even know about the BG2HD project until a few days ago so I'll have to educate myself on what is being done there and how it might be merged with other technologies that are already being employed.
  • asmlasml Member Posts: 5
    Hi @Zorutar, thanks for the pointer. Agreed, let's keep it in one place. For anyone who hasn't seen it, my thread is about rebuilding HD creature sprites from 3D models: https://forums.beamdog.com/discussion/90873/idea-rebuilding-hd-creature-sprites-with-ai-image-to-3d-ie-autospriter-worth-a-pilot
    Here's how that idea fits into your overview.

    Where it fits
    It's a concrete take on your option 3 (recreate animation sets with new 3D models rendered into IE-style sprites), with AI limited to the first draft (your option 2). An image-to-3D model (Hunyuan3D, TRELLIS…) gives a base mesh from the original frames. Then a human cleans it up, rigs and animates it, and IE AutoSpriter, @Incrementis' Blender add-on that renders Infinity Engine sprites from 3D models, renders it at 2x or 4x. On your restoration / reconstruction / recreation question, I'd call it a faithful reinterpretation: the original frames remain the reference for silhouette, colours, poses and timing.

    It also stays within your "not a remake" rule. The HD frames would be displayed at the original world scale, the way the Enhancer handles tiles, so coordinates, movement speeds, selection circles and triggers don't change. Whether the engine can do this for creature BAMs is the key open question.

    What it adds
    - Consistency between frames. Per-frame generative AI (like the sprite experiments @Sour mentioned) invents something different on every frame and direction. A rigged model doesn't.
    - Exact colour remapping. Colourable areas (armour, skin, hair) can be rendered as material masks that map onto IE palette gradients. Frame centre points can be generated so selection circles stay under the feet.
    - A path for paperdoll characters: one rigged body with separate armour, weapon, shield and helmet meshes, rendered into the existing animation layers.
    - It complements rather than competes: x4 backgrounds from @theforgotten69's work, x2 upscaled sprites from the BG2 HD Visual Project, and 3D re-renders where upscaling reaches its limits.

    On platforms
    Native support on Apple Silicon Macs is one of my main concerns: I play on an M1, and while the art itself is platform-neutral, the runtime side of the current HD projects (EEex, DLLs) is Windows-only. In my thread I asked whether tile scaling could work through shader replacement alone. It does. The Mac build of the EE (2.7.3, native on Apple Silicon) loads GLSL shaders from the override folder, and a replacement tile shader can draw x4 tiles at the original scale with no EEex and no DLL. I've validated it in game with an x4 test pack on BG2EE, and TheForgotten69's full BGEE pack installs the same way (in-game check in progress). So for backgrounds, the EE route doesn't have to be Windows-only. Where possible, it would be great if the shared approach favoured content and shaders over runtime hooks, so Mac (and probably Linux) players can follow. I'll post the details in the InfinityEngine-Enhancer thread.

    Suggested next step
    A small pilot: one non-paperdoll creature (a wolf, since AutoSpriter has a wolf demo), rendered at 2x and 4x and compared in game with the original and with an upscale. That would give a real cost per animation set, and answer your team-size question with data rather than guesses. I can help with coordination, documentation and testing, especially on macOS. I'm looking for someone with Blender rigging experience to build it with.

    asml
  • IllustairIllustair Member Posts: 899
    Glad to know that you're using Mac. i'm using Mac more often nowadays myself. Keep us updated.
  • ZorutarZorutar Member Posts: 62
    @Sour Thanks, your practical setup is very useful context. I agree that one of the interesting questions is not necessarily which single approach is “best”, but which existing techniques can complement each other. BGGO as a source combined with higher-resolution rendering/restoration is particularly interesting.

    @asml Thanks for the detailed breakdown. Your proposed wolf pilot sounds like exactly the kind of small proof of concept that could give us real data on workload and quality instead of just speculating. The macOS/shader findings are also very valuable, especially if we want the broader approach to stay as platform independent as possible.

    @Illustair Good to know there are more Mac users following this as well. Cross-platform support is definitely something worth keeping in mind from the beginning rather than trying to solve it later.

    Please keep posting any experiments, results, screenshots or technical findings here as well. I’d really like this thread to remain one of the central places where we collect the different approaches and see how they might eventually fit together.
Sign In or Register to comment.

2026 Overhaul Games, a division of Beamdog. © 2026 Hasbro, Inc. All Rights Reserved. Baldur's Gate, Dungeons & Dragons, D&D, Forgotten Realms, Baldur's Gate, Wizards of the Coast and their logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of Hasbro, Inc. and are used with permission. © 1998 BioWare Corp. All Rights Reserved. BioWare, the BioWare Infinity Engine and the BioWare logo are trademarks of Bioware Corp. Black Isle Studios and the Black Isle Studios logo are trademarks of Interplay Entertainment Corp. Atari and the Atari logo are trademarks owned by Atari Interactive, Inc. All other trademarks are the property of their respective owners.