Two questions: semi-advanced

[YM]

The first: This is the semi bit - What is the default size for cubemaps? I've found a new setting that lets you make them any power of 2 untill 256 - which I thought was the default.... but OMG it makes such a nice finish!!!! (see pic)


The second: this is the advanced one - How do i find those damn degenerate faces? Interlopers says that they aren't a problem and to ignore them, but I don't want to ignore them! I want them gone so that my map is 'error free'

.. extra material..


Mirror shine:

 

[dirtyminuth]

The first: This is the semi bit - What is the default size for cubemaps? I've found a new setting that lets you make them any power of 2 untill 256 - which I thought was the default.... but OMG it makes such a nice finish!!!! (see pic)

Default size is 32x32. Source: http://developer.valvesoftware.com/wiki/Env_cubemap

 

[YM]

wow thats tiny! no wonder 256 gives an almost mirror shine compared.

 

[DrHaphazard]

So uh whats the deal then? I have to assume the 256 is more grahpic intensive? And if so how much more so?

 

[YM]

Performance

The env_cubemap entity allows the user to define how large the target cubemap’s texture resolution is. While a larger texture resolution will provide more accurate and “sharp” results when sampled, it also incurs a cost in texture memory. Most cubemaps should only use the default setting in the env_cubemap entity for their texture resolution (32x32 pixels for each surface). This is generally acceptable in normal conditions. Some exceptions may be necessary for areas of high reflectivity or detail, such as set-pieces for acting.

Because surfaces must approximate their surroundings via cubemaps, using too many cubemaps in a small area can cause noticeable visual discontinuities when moving around. For areas of high reflectivity, it is generally more correct to place one cubemap in the center of the surface and no more. This avoids seams or popping as the view changes.

To determine the cost of cubemaps in any one area, first look at the World Rendering category using the +showbudget console command. If this category is registering an unusually high cost, it may be due to using too many cubemaps in an area. A simple solution to check for this scenario is to use Hammer to Hide all the cubemaps in the map, and then compile and run the map again. If the performance is noticeably better, cubemap density or resolution may need to be reduced. Eventually this can also be checked by turning off cubemaps, by using r_spetacular 0 to disable it, however this needs confirmation.

If 32x32 is normal I would imagine bumping all cubemap sizes up to 256 would be far mroe graphicly intense, I do not intent do do this, 32x32 is fine for almost all cubemaps, but now I've seen the 256 ones I will be using those for the control point cubemaps and only the control point cubemaps.

 

[Snipergen]

didnt even know this, cool. Mirrors eyy =)

 

[TheBladeRoden]

That's gonna go straight into the filesize

 

[Earl]

32x32 = 1,024

256x256 = 65,536

So using a larger values causes each cubemap to take up to 64 times the texture memory -- and filesize in your map.

 

[Dox]

Dieter says: That cake will go strait to my thighs
Mapper says: Those cubemaps will go strait to my filesize
I say: Bubbles!!!

 

[YM]

Ok, so does no one know a way of finding degenerate faces?

 

[Spacemonkeynz]

what is a degenerate face?

Is it an error showing up in the check for errors dialog? Because usually if you just double click on the error it will show you where it is.

 

[YM]

No they don't show up on the check for errors thing in hammer, they come up in the compile log. They don't actualyl cause any problems, what they are:
You're editing a brush in the vertex maniplulation tool, you drag two coners together to make the once cubeoid brush a triangular prism and you accidentaly say no to "merge these two verticies" They you have a face which has a surface area of 0 and you are unable to remove it without clipping that part of the brush off (afaik)