 |
Did it work properly in 2.09? If not, then when was the last time it worked properly? =) |
 |
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. |
 |
Svn 9716 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
Ok, so it probably not even a cubemap, just some texture to be used on projected light? |
|
|
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. |
 |
Cool if you can get it working :) Sounds sorta like: https://forums.thedarkmod.com/index.php?/topic/20332-rendering-real-rooms-without-building/ |
|
|
Yeah exactly this! |
 |
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. |
|
|
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)... |
|
|
@Stgatilov, player view only partly fixed it, the view was facing the correct way but was flipped from left to right. |
|
|
Testing in 2.12b1 this 'appears' to be broken again. Have attached a test map |
|
|
@bikerdude What is broken again - view angle? |
|
|
@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) |
|
|
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. |
|
|
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. |
|
|
Tested @Duzeko's patch and its fixed the issue, only minor issue is the text is mirrored in the cubmap image1.webp (183,656 bytes) |
|
|
@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 |
|
|
@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 |
|
|
So in a nutshell, mappers will just have to manualy flip one or more of the images..? |
|
|
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. |
|
|
What ever you guys think is best to get this function would be very much appreciated. |
|
|
@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. |
|
|
In absence of further discussion, committed to svn rev: 10624 |
- Anonymous
