View Issue Details

IDProjectCategoryView StatusLast Update
0005796The Dark ModDesign/Codingpublic14.01.2024 06:28
ReporterBikerdude Assigned Toduzenko  
PrioritynormalSeverityfeatureReproducibilityalways
Status assignedResolutionreopened 
PlatformPCOSWindowsOS Version10 (21H1)
Product VersionTDM 2.09 
Summary0005796: Envshot is broken again - 2.12b1
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.

Relationships

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 

Activities

Bikerdude

Bikerdude

03.11.2021 23:08

reporter  

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

stgatilov

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? =)
Bikerdude

Bikerdude

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.
duzenko

duzenko

17.12.2021 09:20

developer   ~0014592

Svn 9716
Bikerdude

Bikerdude

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.
stgatilov

stgatilov

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.
Bikerdude

Bikerdude

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.
stgatilov

stgatilov

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.
Bikerdude

Bikerdude

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).
stgatilov

stgatilov

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.
Bikerdude

Bikerdude

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.
stgatilov

stgatilov

07.01.2022 17:21

administrator   ~0014659

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

Bikerdude

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.
nbohr1more

nbohr1more

07.01.2022 20:29

developer   ~0014661

Cool if you can get it working :)

Sounds sorta like:

https://forums.thedarkmod.com/index.php?/topic/20332-rendering-real-rooms-without-building/
Bikerdude

Bikerdude

08.01.2022 00:01

reporter   ~0014662

Yeah exactly this!
Spooks

Spooks

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.
stgatilov

stgatilov

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)...
Bikerdude

Bikerdude

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.
Bikerdude

Bikerdude

23.12.2023 13:19

reporter   ~0016268

Testing in 2.12b1 this 'appears' to be broken again. Have attached a test map
envshot.pk4 (2,128,514 bytes)
duzenko

duzenko

23.12.2023 17:23

developer   ~0016269

@bikerdude
What is broken again - view angle?
duzenko

duzenko

24.12.2023 07:47

developer   ~0016280

@stgatilov
Patch attached
Can you check why screen cubemaps are mirrored on surfaces? Maybe incorrect processing in R_LoadCubeImages?
RenderSystem_init.cpp.patch (3,100 bytes)   
Index: RenderSystem_init.cpp
===================================================================
--- RenderSystem_init.cpp	(revision 10604)
+++ RenderSystem_init.cpp	(working copy)
@@ -1241,13 +1241,13 @@
 	renderView_t ref;
 	viewDef_t primary;
 	int	blends, size;
-	bool playerView = false;
+	int playerView = 0;
 
 	if ( !tr.primaryView ) {
 		common->Printf( "No primary view.\n" );
 		return;
 	} else if ( args.Argc() != 2 && args.Argc() != 3 && args.Argc() != 4 ) {
-		common->Printf( "USAGE: envshot <basename> [size] [blends|playerView]\n" );
+		common->Printf( "USAGE: envshot <basename> [size] [blends|playerView|playerBackView]\n" );
 		return;
 	}
 	primary = *tr.primaryView;
@@ -1256,8 +1256,10 @@
 	blends = 1;
 	if ( args.Argc() == 4 ) {
 		size = atoi( args.Argv( 2 ) );
-		if( !idStr::Icmp(args.Argv( 3 ), "playerView") )
-			playerView = true;
+		if ( !idStr::Icmp( args.Argv( 3 ), "playerView" ) )
+			playerView = 1;
+		else if ( !idStr::Icmp( args.Argv( 3 ), "playerBackView" ) )
+			playerView = -1;
 		else
 			blends = atoi( args.Argv( 3 ) );
 	} else if ( args.Argc() == 3 ) {
@@ -1274,41 +1276,48 @@
 	axis[0][0][0] = 1;
 	axis[0][1][1] = 1;
 	axis[0][2][2] = 1;
+	// back = west
+	axis[1][0][0] = -1;
+	axis[1][1][1] = -1;
+	axis[1][2][2] = 1;
 	// left = north
-	axis[1][0][1] = 1;
-	axis[1][1][0] = -1;
-	axis[1][2][2] = 1;
+	axis[2][0][1] = 1;
+	axis[2][1][0] = -1;
+	axis[2][2][2] = 1;
 	// right = south
-	axis[2][0][1] = -1;
-	axis[2][1][0] = 1;
-	axis[2][2][2] = 1;
-	// back = west
-	axis[3][0][0] = -1;
-	axis[3][1][1] = -1;
+	axis[3][0][1] = -1;
+	axis[3][1][0] = 1;
 	axis[3][2][2] = 1;
+	// up, while facing forward
+	axis[4][0][2] = 1;
+	axis[4][1][1] = 1;
+	axis[4][2][0] = -1;
 	// down, while facing forward
-	axis[4][0][2] = -1;
-	axis[4][1][1] = 1;
-	axis[4][2][0] = 1;
-	// up, while facing forward
-	axis[5][0][2] = 1;
+	axis[5][0][2] = -1;
 	axis[5][1][1] = 1;
-	axis[5][2][0] = -1;
+	axis[5][2][0] = 1;
 
-	for ( int i = 0 ; i < 6 ; i++ ) {
+	for ( int i = 0; i < 6; i++ ) {
 		ref = primary.renderView;
 		ref.x = ref.y = 0;
 		ref.fov_x = ref.fov_y = 90;
-		ref.width = SCREEN_WIDTH;// glConfig.vidWidth;
-		ref.height = SCREEN_HEIGHT;// glConfig.vidHeight;
+		ref.width = SCREEN_WIDTH;
+		ref.height = SCREEN_HEIGHT;
 		ref.viewaxis = axis[i];
 		if ( playerView ) {
-			ref.viewaxis = /*axis[1] **/ ref.viewaxis * gameLocal.GetLocalPlayer()->renderView->viewaxis;
+			if ( playerView < 0 ) {
+				ref.viewaxis *= axis[1];
+			}
+			ref.viewaxis = ref.viewaxis * gameLocal.GetLocalPlayer()->renderView->viewaxis;
 		}
 		sprintf( fullname, "env/%s%s", baseName, cubemapFaceNamesCamera[i] );
 		tr.TakeScreenshot( size, size, fullname, blends, &ref, true );
 	}
-	common->Printf( "Wrote %s, etc\n", fullname.c_str() );
+	common->Printf( "Wrote %s, etc. Reloading the texture...\n", fullname.c_str() );
+	sprintf( fullname, "env/%s", baseName );
+	if ( idImage* image = globalImages->GetImage(fullname) ) {
+		image->AsAsset()->Reload( false, false );
+	}
 }
 
 //============================================================================
RenderSystem_init.cpp.patch (3,100 bytes)   
stgatilov

stgatilov

24.12.2023 10:04

administrator   ~0016283

Last edited: 24.12.2023 10:11

Can you just use "cubeMapAxes" global variable that is used to fetch cubemaps in "native layout" in imageBlock_s::SampleCube?
I don't understand the fun of constantly tweaking these coordinate systems.
I think I added this global variable some time ago, and I simply wrote the axes from OpenGL specification...

Also I think TakeScreenshot stores image in human-readable format (see writer.Flip() there) with Y=0 at top, while OpenGL expects Y = 0 at bottom.
So you should flip all face images by Y at some moment.
Or pass a flag which says whether flip is necessary.
stgatilov

stgatilov

24.12.2023 10:32

administrator   ~0016286

Yeah, and regarding envshot in camera layout... just kill it =)

The conversion between native and camera layouts is implemented somewhere deep inside cubemap loading code.
I did not even try to wrap it into functions, because I don't understand why it is needed (aside from backwards compatibility).
I think mappers will be OK with any convention as long as it works properly.
Bikerdude

Bikerdude

24.12.2023 11:49

reporter   ~0016287

Tested @Duzeko's patch and its fixed the issue, only minor issue is the text is mirrored in the cubmap
image2.webp (718,828 bytes)
image1.webp (183,656 bytes)   
image1.webp (183,656 bytes)   
darkmod_dko.7z (5,162,052 bytes)
duzenko

duzenko

31.12.2023 15:48

developer   ~0016304

@stgatilov
You mean to change how envshot works by switching from 'camera' to 'native' output convention?
Two problems I can see with that:
- existing knowledgebase on the forums and wiki that implicitly links envshot to cameraCubeMap - this all needs cleaning/explaining
- we already have envshotGL that seems to do just that - produce cubemaps in 'native' layout
So I'm reluctant to switch envshot that way
duzenko

duzenko

31.12.2023 15:53

developer   ~0016305

@Bikerdude
The problem with horizontal mirroring is that it seems to apply to all existing cameraCubeMap materials - even if it was never noticed
Understandably, I'm reluctant to make this global change with potentially reversing the sun position on skyboxes, etc
Similarly I'm not sure if it makes sense to mirror the output of envshot so that two mirrors result in a correct image direction - chain of wrongs!
I think for the purpose of virtual rooms we can live with mirroring until we come to a consensus on how to check/fix the existing assets
Bikerdude

Bikerdude

31.12.2023 16:09

reporter   ~0016306

So in a nutshell, mappers will just have to manualy flip one or more of the images..?
stgatilov

stgatilov

01.01.2024 12:48

administrator   ~0016310

No, my idea was to kill envshot command and only support envshotGL.

Otherwise you need to extract the code from cubemap loading to several functions:
  ConvertCubemapCameraToNative (code is already there)
  ConvertCubemapNativeToCamera (I guess can be easily obtained from the previous one)
Then you can always take native-layout screenshot, but additionally call ConvertCubemapNativeToCamera on the result if "envshot" was called.
Bikerdude

Bikerdude

01.01.2024 17:54

reporter   ~0016312

What ever you guys think is best to get this function would be very much appreciated.
duzenko

duzenko

04.01.2024 05:52

developer   ~0016321

Last edited: 04.01.2024 05:52

@stgatilov
Re cubeMapAxes. It seems that it has cube faces in a different order than cubemapFaceNamesNative. So more changes in other areas will be necessary.
Re envshotGL. It exhibits the same mirroring as envshot for me.
duzenko

duzenko

14.01.2024 06:28

developer   ~0016368

In absence of further discussion, committed to svn rev: 10624

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
23.12.2023 13:19 Bikerdude Note Added: 0016268
23.12.2023 13:19 Bikerdude File Added: envshot.pk4
23.12.2023 17:23 duzenko Note Added: 0016269
23.12.2023 20:00 Bikerdude Summary Envshot is broken again - 2.10 x64 => Envshot is broken again - 2.12b1
24.12.2023 07:47 duzenko Note Added: 0016280
24.12.2023 07:47 duzenko File Added: RenderSystem_init.cpp.patch
24.12.2023 10:04 stgatilov Note Added: 0016283
24.12.2023 10:10 stgatilov Note Edited: 0016283
24.12.2023 10:11 stgatilov Note Edited: 0016283
24.12.2023 10:32 stgatilov Note Added: 0016286
24.12.2023 11:49 Bikerdude Note Added: 0016287
24.12.2023 11:49 Bikerdude File Added: image2.webp
24.12.2023 11:49 Bikerdude File Added: image1.webp
24.12.2023 11:49 Bikerdude File Added: darkmod_dko.7z
31.12.2023 15:48 duzenko Note Added: 0016304
31.12.2023 15:53 duzenko Note Added: 0016305
31.12.2023 16:09 Bikerdude Note Added: 0016306
01.01.2024 12:48 stgatilov Note Added: 0016310
01.01.2024 17:54 Bikerdude Note Added: 0016312
04.01.2024 05:52 duzenko Note Added: 0016321
04.01.2024 05:52 duzenko Note Edited: 0016321
14.01.2024 06:28 duzenko Note Added: 0016368