Task #924

Test cube maps

Added by thunder over 3 years ago. Updated 2 months ago.

Status:Invalid% Done:


Priority:LowSpent time:-
Target version:renderer2
OS: Arch:


is this possible to implement?

would be much easier with skyboxes then

Related issues

Related to ET: Legacy Development - Bug #621: renderer2: Skybox issues on some maps Fixed 11.11.2014


#1 Updated by keMoN over 3 years ago

What exactly is it you want implemented? I don’t seem to understand, sorry.
The skybox in W:ET also consist of 6 different textures, like the 'cubemap’ presented in this post?

#2 Updated by IR4T4 over 3 years ago

  • Category set to General
  • Target version set to 2.75

#3 Updated by thunder over 3 years ago

I meant the picture the way it is kemon, a cubemap as a cubemap.. Dont know how to explain it. but I think CS is amongst those who use it this way...

#4 Updated by IR4T4 over 3 years ago

  • Target version changed from 2.75 to 2.76

#5 Updated by keMoN about 3 years ago

I don’t think this is a good idea. The only benefit I see is more convenience for the person who is creating/modifying the skybox texture, since it wouldn’t be needed to create a larger canvas in Photoshop and manually place them next to each other for editing.
The larger canvas brings me to a big downside this would bring, We established that even 2048x2048px textures are probably not going to work, that means that the maximum size a texture can have is 1024x1024px. Right now each side of the skybox can be optimized and make use of the full potential of 1024px (or 2048px if we can find out why ET: Legacy has problems where vanilla ET doesn’t).

If we put the whole skybox into one texture like in this cubemap Thunder linked, the overall maximum of 1024 (2048) px doesn’t change, but now each side is restricted to 256 (512) px.

Another technical problem this would bring, is that W:ET is designed to use textures which have a power of 2 as px size. There would be no problem with the width since the four sides make use of the complete potential. However, there are only 3 textures in height, which means that the height of the texture would be 768 (1536) px, which means that we would have to add another 256x1024 (512x2048) row of unused black or make sure ET has no problem with 'uneven’ texture sizes code-wise.

#6 Updated by Mateos about 3 years ago

Several textures are not squares ones in ET assets, it’s fine as long as both dimensions are power-of-two.

Also see https://en.wikipedia.org/wiki/Cube_mapping#Advantages

#7 Updated by keMoN about 3 years ago

I think you might have misunderstood me. I’m not saying there is a problem, because the cube map isn’t square, I’m saying there is a problem because it inherently isn’t power of two.
The width of a cube map is made up of the 4 sky sides. The height is made up of one side plus top and bottom, so 3 sky sides. The height therefore is not a power of 2. We therefore would need to include an area of 256x1024 (512x2048) to make up for the missing 4th square in height. This means unnecessary additional filesize.
If you divide the finished cube map with the additional area into even squares of 256 (512) px, of the existing 16 squares only 6 will be used for the texture.

In my opinion this is way too much waste, if the only benefit is more convenience for the creator/modder.
I will check the link you provided to have a better understanding of the advantages, but as I laid out above, I don’t see the use of this right now.

#8 Updated by Mateos about 3 years ago

Each part of the cube map is a square, in the case of ETL must be a power-of-two one, so game-side you only capture the part of the texture that you’ll apply to the current face you are rendering...

This was used by a lot of recent games after ET due to its simplicity. Source uses this, it’s better than fake environnement like in Breakout 2

#9 Updated by thunder almost 3 years ago

think renderer2 allready got it as I found this in xreal shadermanual:

6.1.2. cubeMap <map> This stage uses a cube map as the image map. Looks for _px, _py, _pz, _nx, _ny, _nz for the positive x, y, z, and negative x, y, z sides.

#10 Updated by IR4T4 almost 3 years ago

  • Subject changed from cube map to Test cube maps
  • Target version changed from 2.76 to renderer2

We don’t have the power and there is no good reason to add this to r1. Let’s focus r2!

#11 Updated by IR4T4 almost 3 years ago

  • Tracker changed from Feature to Task

#12 Updated by IR4T4 almost 3 years ago

  • Related to Bug #621: renderer2: Skybox issues on some maps added

#13 Updated by thunder over 2 years ago

think this is just a "skybox" feature so Kemon can relax.
but we might need to do some changes to it.
look at existing skyboxes to see.

should be looking for .ft - .lf and so on I guess

can look at this one:

#14 Updated by Spyhawk 2 months ago

  • Status changed from New to Invalid
  • % Done changed from 0 to 100

Closing at thunder’s request.

Also available in: Atom PDF