Spawnargs for Cubemaps!

[Epifire]

So there's this really great idea that came to me and I'm not sure if it's being done (and I'm just behind the times) or if it's actually just a really great idea.

 

It's generally agreed by anyone wanting cubemaps in TDM that it's a much greater pain than it should be. Given that other engines of the day have actual cubemap sample nodes to sprinkle around the leve (that applicable objects source automatically) ours is completely manual to setup.

 

I had the idea when I remembered the color input to flag on meshes to override rgb values in the MTR. What if we had a cubemap spawnarg where we could just set a unique cubemap keyname? So much easier! Technically I think we can use some optional parm line to piggyback a value off of but this just seems like it would be easier if we could just flat out type in >cubemap (keyword)< and link the appropriate map.

 

What does this solve you say epi? No more additional material creation for each area using a new cubemap reference!

 

Alright here's the best example. I've got this hella cool reflective hallway with multiple different locations. Now currently if I wanted to make some small reflection captures (say 128x size maps) for six different spots, I'd need six separate MTR definitions to define the separate cubemap keynames. This is what makes cubemaps much more of a novelty item in id4 (just because it's so manual to setup). If we converted our workflow to a variable stage like this, all you'd have to do is envshot your positions in-game and then link that keyname used in the envshot. SteveL already had corrected the cubemap naming that it spits out, so that made this option all the more convenient. We could just start setting new materials up with a description stating it's cubemap variable compatible, so then there's some informative context on the DR side.

 

It still means you gotta set the extra spawnarg for each object but it beats creating new material instances every time. Tell me this doesn't sound rad?

[duzenko]

Does the cubemap reflection work at all now?

[peter_spy]

Not sure if I get what you mean but we are already a step closer to parallax-corrected cubemaps and proper reflections. Not sure if you tested that, but we have ambientCubicLight (not just cubicLight) that projects cubemap reflection onto surfaces. If we could link that with some kind of cubemap sampler, i.e. we'd be able to take an envshot in the position of that given light, and if the cubemap itself was parallax-corrected, we'd be there

 

http://forums.thedarkmod.com/topic/18282-tracker-3881-cubemap-lighting-beta/page-6?do=findComment&comment=414601

[Epifire]

Does the cubemap reflection work at all now?

 

Yes it works but can be finicky to setup. It also lacks parallax correction, so player movement within the environment isn't reflected in the cubemap projection.

 

 

Not sure if I get what you mean but we are already a step closer to parallax-corrected cubemaps and proper reflections. Not sure if you tested that, but we have ambientCubicLight (not just cubicLight) that projects cubemap reflection onto surfaces. If we could link that with some kind of cubemap sampler, i.e. we'd be able to take an envshot in the position of that given light, and if the cubemap itself was parallax-corrected, we'd be there

 

http://forums.thedarkmod.com/topic/18282-tracker-3881-cubemap-lighting-beta/page-6?do=findComment&comment=414601

 

I was giving this a read the other day and I still don't understand fully what the goal is with cubic lights. I can agree, I don't think autosampler positions are out of the question either. I'm very keen on seeing cubemap usage updated and streamlined, as I think it's well within id4's ballpark to do so. The thing that bugs me with cubic lights is that it's not so impartial in terms of it's coverage as it's totally localized (and projected) from a direct source. As cubemaps, at least to my understanding can encapsulate a given mesh oblivious to origin/orientation.

 

All I'm wanting right now is standardized and updated cubemap systems to work with. Then I can start working with reflective based materials with much more accurate results. I'm actually doing a bit of digging right now to see how exactly I'd direct a cubemap keyname via spawnarg. Just as proof of concept that is, I'd like to get the syntax ironed out for this MTR and just find a parm value that can act as a place holder.

[peter_spy]

I only tested it for a while yesterday, but the main difference is that cubicLight projects textures in cubemap, just like a spot light with projection texture would do, but in 6 directions instead of 1. AmbientCubicLight project a cubemap reflection onto surfaces, as if it was added in the material definition itself. So it seems perfect for parallax-corrected solution we discussed before in other threads, reflective floors and whatnot.

[Epifire]

But that wont take normal map distortion (combining with the normals of the material it's casted upon) from cubic lights will it? One of the benefits of it being material based is that the normals would skew the reflection of the cubemap. If you had the time I'd be interested in seeing a cubic light running reflections. Would you care to demonstrate that in the reflection hallway pk4 I uploaded a while back?

 

http://forums.thedarkmod.com/topic/19147-parallax-corrected-cubemaps/

 

I'd be very interested in seeing the results, having a direct comparison of regular reflections present.

[peter_spy]

I'm not sure I'll have the time to do this, but I'm also super curious about the results

 

Just a quick test to show you how it works so far. There are two omni ambientCubicLights here. The light where the player is uses skybox_afternoon_01_cube, while the light at the other end of the room uses skybox_industrial_01_cube. The wall and floor material doesn't use any cubemap.

 

Edited November 16, 2017 by Judith

[VanishedOne]

I wonder whether something could be kludged together using the GUI system (compare the sign decals that read text from spawnargs). But yes, ideally it would be another keyword, like 'sound', that material authors could drop in.

 

This quotation has been knocking around for years...

 

I know have an old quote from Brian (id) that seems to indicate that envshot can be automated via SDK

"You should be able to implement an 'env_cubemap' pretty easily in the code. Take a look at idObjective::Event_CamShot. This is the function that's used to generate the objective screenshot used in that little tooltip window that pops up when you get a new objective. Those screenshots are generated as soon as the map loads."

...so I suppose it's been a matter of programmer time/priorities.

[Epifire]

But yes, ideally it would be another keyword, like 'sound', that material authors could drop in.

 

It would be context specific so you really couldn't make wide use beyond your local files and map for a single project. I think this is for the frob shader but it's closer to something like what we'd need for the material to utlize...

    {
        if ( parm11 > 0 )
        blend       add
        map         models/darkmod/props/textures/rooftop_tiles_001	
        rgb         0.15 * parm11
    }

I'm particularly interested in that if statement followed by the parm. What syntax/operator could I use to pass a keyname along with?

 

Ideally we'd want the parm to carry a keyname value to fill in the blanks. More to the point the data field holding (envsky_seaside) in my example...

    {
        blend gl_dst_alpha, gl_one
        cameraCubeMap   env/envsky_seaside
        texgen skybox
    }

We're only wanting the spawnarg to edit that field. If that can be left as some kind of variable, it means this block could be copied and pasted into other definitions requiring a cubemap. It should extend the usefulness of what would otherwise be extremely map specific materials so other authors could reuse it for their own envshot data.

[VanishedOne]

That's why I thought of GUIs; have a look at the https://www.iddevnet.com/doom3/materials.php notes for guisurf.

 

(Of course guisurf entity or whatever is limited to the material's global scope, which is why I cited sound as an example instead: it tells the material to use the entity's sound output amplitude as a value, and it can be used inside stages.)

 

Edit: on reflection I'm unsure whether you're after compile-time or runtime image selection. I'm talking about stuff that materials do once loaded. But maybe you're contemplating a macro system for material decls like Quake 4's 'guides' or ET:QW's 'tempates'?

Edited November 17, 2017 by VanishedOne

[Epifire]

Yeah that Quake reference is exactly what I'm trying to do. Just substituting the path name via parm to avoid all the extra material work. Meaning less time in the text editor and more time to making things in DR.

 

These parm definitions look to be specific to quake though. I'm still confused as to what's actually declaring the path name in their reference, or what's just a file name. Like, we don't actually have a Glowparm in the D3 code do we?

guide generic_glow(TextureParm, Glowparm)
{
        qer_editorimage textures/TextureParm_d

        bumpmap addnormals ( textures/TextureParm_local, heightmap ( textures/TextureParm_h, 1 ) )
        diffusemap      textures/TextureParm_d
        specularmap     textures/TextureParm_s
        {
                blend           GL_ONE, GL_ONE
                map             textures/Glowparm

                red             Parm0  
                green           Parm1  
                blue            Parm2  
        }
}

For the sake of the argument my spawnarg is called EnvParm. So if I wanted to change the keyname (envsky_seaside) with whatever I set in the EnvParm spawnarg, wouldn't it look something like this?

    {
        blend gl_dst_alpha, gl_one
        cameraCubeMap   env/(EnvParm)
        texgen skybox
    }

Trying to make sense of all this and explain it to the best of my abilities. I'm just trying to figure out how this should be structured so I can start testing away. Hopefully this block can be placed in a lot of my mtr defs when finished, as it should only alter the result when the EnvParm is declared via spawnarg. Quite literally the same thing we do with the color spawnarg and applicable materials that it can alter. If this works as flawlessly as I'd hoped, we can start having materials ready for cubemap projections right out of the box.

[VanishedOne]

I'm afraid templating for material decls is one of those nice things that exists in some id Tech 4 variants but not in the open-source versions. Compared to a multipurpose macro/template system, though, it shouldn't need to be complex.

 

Ideally it would be in-engine (thus cutting down on the size of distributed files), but otherwise see http://forums.thedarkmod.com/topic/18843-material-generator-bash-script/

 

At a glance I think GlowParm is just an arbitrary name, and you 'call' generic_glow() with variables like a script function. Whatever you pass in gets a simple find-and-replace treatment in the template body.

Edited November 18, 2017 by VanishedOne