View Issue Details

IDProjectCategoryView StatusLast Update
0005796The Dark ModDesign/Codingpublic10.01.2022 17:15
ReporterBikerdude Assigned Toduzenko  
Status assignedResolutionreopened 
PlatformPCOSWindowsOS Version10 (21H1)
Product VersionTDM 2.09 
Summary0005796: Envshot is broken again - 2.10 x64
DescriptionPlease see 0005215, 0004868 for how to reproduce. I have attached a test map .pk with all the files required for testing
TagsNo tags attached.


related to 0005215 resolvedduzenko Envshot is still broken as of TDM 2.07 & 2.08 
related to 0004868 resolvedduzenko Envshot is broken as of TDM 2.06 




03.11.2021 23:08


envshot.7z (3,891,228 bytes)


11.12.2021 14:15

administrator   ~0014583

Did it work properly in 2.09?
If not, then when was the last time it worked properly? =)


12.12.2021 10:54

reporter   ~0014585

As an end user, I can't remember when it last worked. But in the above related bug trackers it worked in rev 7581 & 8673.

I attached a test mission that has everything needed diagnose the issue.


17.12.2021 09:20

developer   ~0014592

Svn 9716


07.01.2022 12:41

reporter   ~0014652

Hi Duzenko

Sorry feel a I have had to reopen this tracker as I found a problem, it seems that no matter which direction your facing when you take an ENVSHOT, the game will always have the ENVSHOT face the same direction. So this pretty much renders the function unusable if the mapper cant specify the direction they want the projection to face when taking the shot etc.


07.01.2022 13:47

administrator   ~0014653

Isn't it how things should work?
You set position, then take envmap: then you get full cubemap of the fixed orientation.
Then you apply it to some object, and its replicates the orientation that was originally used.


07.01.2022 14:23

reporter   ~0014654

As fare as I understand it no, The ENVSHOT should always point in the direct I took the ENVSHOT in.

But what is currently happening is regardless of how I set position, then take ENVSHOT. The cubemap chooses its own orientation in-game, not the orientation/direction I chose when taking the ENVSHOT.


07.01.2022 14:35

administrator   ~0014655

If player orientation is taken into account, then aligning env shot would be much harder.
Mapper needs to use setviewpos to produce an axis-aligned cubemap, otherwise he gets something at least slightly rotated.


07.01.2022 14:48

reporter   ~0014656

If the mapper is using ENVSHOT to create fake interiors then the test map with said interior can be rotated prior to taking ENVSHOT.

If the mapper want to create an fake interior/exterior from an existing map they are working it would save a lot of time to not have to create a prefab, place it in a testmap, roatate and then take an ENVSHOT.

For example I just tried to the above in my current WIP, the viewpos I wanted was (603.38 -328.58 81.79 1.1 174.3 0.0), what I got in-game was (603.38 -328.58 81.79 -0.2 -1.4 0.0).


07.01.2022 15:23

administrator   ~0014657

Why do you need rotated env map in the first place?
Given that env map captures full surroundings, wouldn't it be easier to record envmap in standard orientation and then apply it in the same orientation on some object?

I admit I don't know well how are env map used.
Just to compare: when engine generates shadow map, it always computed in fixed orientation in world space, and all usages also use this orientation.
It is must simpler than trying to add all kind of world-light rotations.


07.01.2022 16:36

reporter   ~0014658

Typically when you take an ENVSHOT to create a fake interior/room, you want the view to be of looking into said room through a windo. So when the mapper takes and ENVSHOT its with his back to this window.


07.01.2022 17:21

administrator   ~0014659

Ok, so it probably not even a cubemap, just some texture to be used on projected light?


07.01.2022 19:44

reporter   ~0014660

Not a light, but a patch to be placed inside a window. Have a look at Kvorning's Lords & Legacy, he had the right idea, but had to do it the hard way by building lots of inaccessible interiors.


07.01.2022 20:29

developer   ~0014661

Cool if you can get it working :)

Sounds sorta like:


08.01.2022 00:01

reporter   ~0014662

Yeah exactly this!


10.01.2022 13:50

reporter   ~0014664

I don't think that application is very typical and I do not recall envshots ever working with the player view like that. If anything I'd peg this (note 0014656) as a feature request rather than a bug. That said, I'm not opposed to it; if it's a command line argument to envshot the same way "noflood" is to dmap it will certainly provide more flexibility.


10.01.2022 15:09

administrator   ~0014665

I think it was written on Discord that envshot already has "playerView" optional parameter, which does take player orientation into account.
If it works as intended, I think this issue can be closed (as resolved)...


10.01.2022 17:15

reporter   ~0014666

@Stgatilov, player view only partly fixed it, the view was facing the correct way but was flipped from left to right.

Issue History

Date Modified Username Field Change
03.11.2021 23:08 Bikerdude New Issue
03.11.2021 23:08 Bikerdude File Added: envshot.7z
03.11.2021 23:09 Bikerdude Relationship added related to 0005215
03.11.2021 23:09 Bikerdude Relationship added related to 0004868
11.12.2021 14:15 stgatilov Note Added: 0014583
12.12.2021 10:54 Bikerdude Note Added: 0014585
17.12.2021 04:55 duzenko Assigned To => duzenko
17.12.2021 04:55 duzenko Status new => assigned
17.12.2021 09:20 duzenko Status assigned => resolved
17.12.2021 09:20 duzenko Resolution open => fixed
17.12.2021 09:20 duzenko Note Added: 0014592
07.01.2022 12:41 Bikerdude Status resolved => feedback
07.01.2022 12:41 Bikerdude Resolution fixed => reopened
07.01.2022 12:41 Bikerdude Note Added: 0014652
07.01.2022 13:47 stgatilov Note Added: 0014653
07.01.2022 14:23 Bikerdude Note Added: 0014654
07.01.2022 14:23 Bikerdude Status feedback => assigned
07.01.2022 14:35 stgatilov Note Added: 0014655
07.01.2022 14:48 Bikerdude Note Added: 0014656
07.01.2022 15:23 stgatilov Note Added: 0014657
07.01.2022 16:36 Bikerdude Note Added: 0014658
07.01.2022 17:21 stgatilov Note Added: 0014659
07.01.2022 19:44 Bikerdude Note Added: 0014660
07.01.2022 20:29 nbohr1more Note Added: 0014661
08.01.2022 00:01 Bikerdude Note Added: 0014662
10.01.2022 13:50 Spooks Note Added: 0014664
10.01.2022 14:02 Bikerdude Severity normal => feature
10.01.2022 15:09 stgatilov Note Added: 0014665
10.01.2022 17:15 Bikerdude Note Added: 0014666