P4: Lab: a background mission's $Environment Map is never used

Open Beginner friendly
  • Is something wrong?
#7,932 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
Half a day
Newbie friendliness
66/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
cpp
Domain
computer-graphics, game-dev

Research direction

Start in LabRenderer::useBackground, where the mission's $Environment Map is read into envmap_name but The_mission.envmap_name is loaded instead. Compare with environment_map_gen in starfield.cpp, then check the ENVMAP > 1 test that follows. Done when a ship in the lab takes on the background mission's environment map colors, matching the mission. Testing needs a cubemap mission and an OpenGL debug build.

Written by the indexing model from the issue text.

Description

This is minor: it only affects the F3 lab's preview, not missions.

Problem

When you pick a mission as the lab's background, the lab loads that mission's stars, suns and bitmaps but ignores its $Environment Map. Ships in the lab don't reflect the environment map the mission names, so the lab preview doesn't match what the ship looks like in that mission.

Steps to reproduce

  1. Current master (8afa31842), debug build, Linux, OpenGL, MediaVPs 5.0.2.
  2. Use a mission whose $Environment Map is a cubemap with obvious colors. I used a test mission with a 64x64 cubemap that has one bright color per face.
  3. Open the lab (F3), show a GTC Fenris, then pick that mission under Mission Background.
  4. Compare with the same Fenris in that mission.

Expected vs. actual behavior

Expected: the Fenris in the lab picks up the environment map's colors, like it does in the mission.

Actual: the background loads (the stars appear), but the hull stays plain grey. In the mission, the same map tints the whole hull.

From reading the code: LabRenderer::useBackground reads the mission's $Environment Map into a local envmap_name, but then loads The_mission.envmap_name instead, which in the lab is empty or left over from the last mission played. So the background's map is never loaded. I haven't tested the case where the leftover name points at a flat (non-cubemap) texture; by reading, it could hit the same OpenGL crash as #2245.

Proposed fixes

  1. Load envmap_name (the name just read) instead of The_mission.envmap_name, and change the ENVMAP > 1 check right after it to >= 0.
  2. Same as 1, plus the cubemap check from #7930, so a flat texture falls back to the generated map in the lab too.
  3. Share one helper between the lab and environment_map_gen in starfield.cpp, so both load and check the mission's environment map the same way.
Dominant language
C++
Stars
488
Forks
184
Avg merge
1d 19h
Merged PRs (30d)
32

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from scp-fs2open/fs2open.github.com

All issues in scp-fs2open/fs2open.github.com

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.