Very unmodest proposal about cubemap implementation.

[Capewearer]

Darkplaces is very advanced Id Tech fork – it has realtime lights, parallax mapping, deluxe maps and other fancy stuff. But it has some weird limitations – like having one cubemap at one game map. It may work for arena-styled environments (imagine Colloseum for example), but it’s incorrect approach for any kind of other layouts. Because I am not skilled enough to implement it myself, I may only describe some ideas about how it could be programmed, if anyone from Xonotic/Darkplaces team has such intention. I understand it’s not first-importance goal, but anyway, I hope we’ll get this next year. In defense of my proposal, it’s partially implemented functionality with shader parameters like dpReflectCube. Here’s a specification for external (like .lit file for Quake 1 or .rtlights) cubemap file format. It has .cub extension, it’s text-based with such approach: in the first line it writes folder name, where all the cubemaps are stored. Then it evaluates a list of cubemaps (one per each line) with data layout like this: x0 y0 z0 x1 y1 z1 name Let me explains what these coordinates mean. You have to create somehow the cubemaps and define area of their action, right? The only way I imagine is creating special brush entities for Netradiant editor. Let’s call it func_cubemap. Imagine you create cuboid axis-aligned detail_brush with special name, having a special postfix “-func_cubemap”. Then it gets processed with map compiler, producing outputs in .tga textures. So these coordinates are integer coordinates of opposite corners of such cuboid. Processed cubemap works in range of this cuboid, being shot from cuboid center (obviously, its coordinates are (x0 + x1) / 2, (y0 + y1) / 2, (z0 + z1) / 2). Name of cubemap simply defines how six .tga textures would be named. It would be named like this: name + eval(“py”, “pz”, “px”, “ny”, “nz”, “nx”). Now let’s imagine how would look .cub file with two cubemaps: cubemaps 0 0 0 100 100 100 map1 0 0 0 -100 -100 -100 map2 It means that map creator has put two func_cubemap entities on .map file and wished to store 12 generated textures in /cubemaps folder. Texture names are: map1py, map1pz, map1px, map1ny, map1nz, map1nx, map2py, map2pz, map2px, map2ny, map2nz, map2nx. What about parallax corrected cubemaps? If this ever gonna happen (very unlikely), I believe it could be turned on in setting. Like, if user wants parallax correction, user wants it applied to all cubemaps, right? File format also could be extended with scriptable cubemaps. Just imagine environment shot being caused by QuakeC script. It could be used to update cubemaps in destructible environments. Of course, that’s not cheap for rendering, but it could be nice feature. I believe there shall be issue with brush surfaces that are long enough to capture two or more cubemaps.

[Baker7]

What kind of an effect are you looking to do? Do you have a screenshot?

I ask because I am interested in nice effects in Q3 maps.

[Capewearer]

As you can see, there's a metallic plate on back of Erebus playermodel in Xonotic game. You can see that white reflex, right? There's no white surface lights in this part of map. It happens because there's only one cubemap. That's also the reasons why materials are so rough (to hide this imperfection).

[Cloudwalk9]

Putting this down as a bug because this is definitely an odd limitation that defeats the purpose of having cubemaps in the first place, so it may as well be treated as one.

[Shpoike]

https://developer.valvesoftware.com/wiki/Env_cubemap

[Baker7]

Going to throw some shader stuff in here.

First, @ shpoike Q3 BSP 47 in fte 6446 ... map mp_vietnam https://www.breezie.be/rtcw/mapdownloader/mapdetail.php?id=38

Got some bad vertices or something.

I was comparing and contrasting FTE bsp 47 support vs. ChaosAnthology Xonotic which seems to be based off DarkPlaces 2012 and the implementation of bsp 47 feels incomplete, my interest is the higher resolution lightmaps that bsp 47 allows.

======

DarkPlaces ... ran into a map mxl_school.bsp ... similar cubemap issues as op

DarkPlaces beta does not recognize "exactVertex" shader param, gets fullbright trees in this pic:

After having "exactvertex" degrade to "vertex" (q3 shader reference has technical details I was reading through, but it appears to be only overbrights ...)

However, what is supposed to look like, with the UFO having a cube map .. open arena pic ...

[Shpoike]

that's an envmap, not a cubemap, and thus offtopic (dp only supports a single(+lightmap) pass, so cannot be expected to draw such things properly).

[Cloudwalk9]

@Shpoike Thanks for clarifying. A bit rusty with the engine. Not a bug-equivalent then, just a missing feature and works as intended. I still would love to see parallax cubemaps implemented.

[Baker7]

@capewearer ...

Could you post the Q3 shader text that you would like to work? My imagination sucks, so I need a example in front of me.

I looked through the dpreflectcube process, which is the closest thing in the engine to doing 2 textures at once for a shader AFAIK and it does not take a parameter except the texture name.

I want to scope out how much work to plot through the GLSL and extend the functionality a little and maybe have a 2nd texture option in there.

No promises, but I'm a bit curious because I like the env and cubemap effects on shiny stuff.

And I have a Sherlock Holmes mystery to unlock anyway ...

DarkPlaces Classic glass in mxl_school.bsp (in Zircon Alpha 60)

DarkPlaces Beta glass in mxl_school.bsp (in Zircon Beta # 26)

I want to look through and see what changed and where.

[Shpoike]

cloudwalk, technically my reply was to Baker, but yeah, capewearer's original post is a feature request rather than an actual bug.

basically the 'dpreflectcube' directive in the shader would go away, replaced by the cubemap generated from the nearest env_cubemap/equivalent (or just the map's skybox as a fallback). the reflectmask directive would be retained effectively taking over enablement, defining a texture that provides both the tint and shinyness as it were. basically just an extra reflectcube*reflectmask additive term (doesn't need lighting as lighting levels are meant to be baked into the cubemap already, although toggled lights will be an issue shared with q3bsp's static lighting). the down side is that you may find you need to blend multiple cubemaps together, so you don't end up with sudden changes on your viewmodel when you move from one area to the next.

FTE has had some bspx lumps for this for a while, for per-surface cubemap selection instead of needing to create per-area variants of each material, so its much easier to actually use. Someone provides textures+shaders, all the mapper-hatted person then has to do is to slap a few more ents into the map and remember to use a console command before release. a PBR IBL pipeline would generally want two separate cubemaps for each point/area, with mipmaps to account for different levels of blurring so generation of cubemaps is likely to remain somewhat engine-specific. With Nuclide+FTE, the csqc generates the cubemaps (by invoking the appropriate screenshot_cubemap console command with the camera placed correctly for each without extra 2d overlays, with some extra timer stuff to handle serverside vis between captures), while the engine has a mod_findcubemaps command to inject the compute lumps as needed (though it'd be better for qbsp/q3map2 to do this, potentially allowing greater control). combined they give something vaguely equivalent to hl2's cubemap reflections. But not PBR-friendly cubemaps. :(

[Baker7]

In retrospect, I am understanding Spike's comment about "off topic" more.

When I see "cubemap" about 6 different things come to mind, and because I use "dpreflect cube" for inexpensive "shiny texture effects" (like building pictured below .. but that cubemap is not of the scene), I was not immediately seeing that this is more related to a cubemap based on the player's current position like the Valve link and Spike is saying he has FTE do with "screenshot_cubemap" with the current camera.