[Bf-gamedev] Cube Map rendering (Cycles)

Forest Hale havoc at ghdigital.com
Tue Sep 17 00:12:28 CEST 2013


Most engines are D3D centric and use a single .dds file, which is the cleanest representation to be sure but many people do not even realize that a .dds file can contain uncompressed BGRA pixels in
the first place and may instead create such files with DXT1 which will mutilate the quality on a cubemap or skybox in practice as these tend to have significant gradient areas.

The hardware preference matches Renderman, where positive and negative X, Y and Z images are stored in order as a single 1x6 film strip (a 6x height image in other words), and in D3D the mipmaps are
stored as additional film strips, essentially this layout reduces the problem to a specific 2D image layout.

It is unlikely that any engines use 3x2 or 2x3 (or 6x1) layouts for the images because these are not agreeable to the inevitable hardware uploads that will occur, similarly I highly doubt there are
any "cross type" cubemaps in the wild as these would waste significant memory during loading before conversion to the 1x6 film strip layout for hardware.

Of more paramount concern is the fact that different engines orient the cubemaps differently - that is to say, in id Tech engines you can count on X being East, Y being North and Z being Up, but in
some other engines these are different directions, for instance another common layout is to have X = East, Y = Down, Z = North, and variations thereof, depending on whether it is a right handed
coordinate system or left handed coordinate system, as well as "personal preference" on the part of the person writing the engine framework in the first place.

The id Tech 4 standard is the following naming scheme:
foo_px.tga
foo_nx.tga
foo_py.tga
foo_ny.tga
foo_pz.tga
foo_nz.tga

The common skybox format I've come across is one originating in 3dsmax, which is not directly usable as a cubemap:
foo_ft.tga
foo_lf.tga
foo_bk.tga
foo_rt.tga
foo_up.tga
foo_dn.tga

Conversion from/to skybox format is quite doable but involves transposing (swapping rows for columns) and mirroring rows/columns for certain conversions - much the same sort of work you would be doing
for reorienting a cubemap however, so this functionality "Just makes sense".

My Quake engine DarkPlaces is my prime concern of course, and it can load a skybox as a cubemap or vice versa, among other conversions at load, this engine is used in a handful of (mostly open source)
standalone games such as Steel Storm, Blood Omnicide, Nexuiz, Xonotic, Darsana and others.

The reason I brought up the topic of using Cycles to render out to a cubemap was for a different project however, where I wanted to put a cubemap on a water surface, and found Cycles materials to be
easier to work with than Blender Internal materials, then found myself without an easy solution when I found Cycles had no ability to render out to cubemaps.

So this was a relatively trivial "asset production" use case where I wanted to produce a cubemap, and found myself facing the prospect of creating 6 cameras - a doable and reasonable solution but I am
certain this is an issue that will come up again and again with the significantly increasing use of Blender for game development, many small game studios would gladly produce rendered art assets (such
as skyboxes) with Blender, not just models.

Unfortunately a bit of my intention was lost in translation when my colleague submitted this as a feature request without fully grasping all the nuances of the request itself, the core points should
be clear now.

On 09/16/2013 02:44 PM, Dalai Felinto wrote:
>> Every engine I've worked in stores cubemaps in one file but skyboxes (...) in six. Engine texture compilers might also consume separate files for each cubemap face even if the result is stored in one combined file.
> 
> Could you be a bit more specific in the engines/specs here?
> 
> For example:
> engine X use 1 image with Top-Back-Bottom/Left/Front/Right
> engine Y uses 6 images for skybox but also can take 1 image ordered like X
> engine Z uses ...
> 
> Or at least some names/links/references.
> Hopefully we can find a standard we can follow and keep things simple.
> 
>> (...) one aspect of that is determining the location of each face in a combined output image. It's already possible to do that, there's just no GUI for it...
> 
> Are you referring to the Environment Map panel?
> http://www.pasteall.org/pic/59432
> 
> What do you mean by 'it's already possible to do it, but not through the gui'? How are changing the cubemap order at the moment?
> 
> * * *
> 
> Apart from that I think Cycles supporting this format has vantages on its own. I know people that advocate for Cube Maps over panoramas as the de facto format the industry should adopt (e.g., words
> from Paul Bourke).  
> 
> Thanks,
> Dalai
> 
> 
> 
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
> 


-- 
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier



More information about the Bf-gamedev mailing list