A Utopia At Stake Created 5 years ago2019-01-16 00:46:21 UTC by Admer456

Yes that's what I thought - the client gets a read-only view of entities, and I remember trying to get the texture data for models or sprites but couldn't find a way.

Nice work with the big maps - looking forward to the tutorial.

"I remember trying to get the texture data for models or sprites but couldn't find a way."

At that point I'd probably do a MDL and SPR parser, if I just wanted to read the texture data. It'd be easy too, there are several open-source apps doing that stuff, so, we can use it as a reference / steal the code.

And thanks, I will most likely write it around late May or early June. I'm trying to focus on my game project, school and some tough emotional problems, so it's gonna take a while.

The other day, I was thinking about how SOLIDHINT was nice, but it didn't have the properties of BEVEL.
And that was a real dilemma for my terrain design decisions. D:
Should I use SOLIDHINT and have cleaner BSP cuts, or should I use BEVEL and have smoother collision on edges of brushes?

So, I thought to myself, why not both?
Today, I went ahead and made that happen. It works!

Definitely gonna release the compilers as soon as Advanced Development Mod 0.1 comes out.
In other news, I restructured the mod base code a little bit.The next step will be to separate all classes into their own files, since there are tons of .cpp files with multiple different entity classes defined in them. Yuck.
Next post will probably be in summer.

At that point I'd probably do a MDL and SPR parser, if I just wanted to read the texture data. It'd be easy too, there are several open-source apps doing that stuff, so, we can use it as a reference / steal the code.

Oh agreed - I was just hoping the data was modifiable at runtime.

It seems that BOLIDHINT works.

In my test map, bigterrain2.bsp (shown somewhere above), I textured all the backfaces (except the one of the very flat ground) with BEVEL, NULL, SOLIDHINT and then BOLIDHINT. The results are kinda interesting.

Firstly, let's take a look at the wireframes:*594, probably because one of my view angles was just 1 or 2° off, but it'd be 592 otherwise.

So, if we look directly at the wireframes, BOLIDHINT is apparently the same as SOLIDHINT. However, now let's look at the clipnode counts:
NULL - 7148 clipnodes
BEVEL - 4318 clipnodes
SOLIDHINT - 7158 clipnodes
BOLIDHINT - 4122 clipnodes
NULL and SOLIDHINT aren't supposed to create the same number of clipnodes, considering the fact that SOLIDHINT generally produces less wpolys. Keep that in mind.
Worldfaces, worldleaves, marksurfaces, vertices, nodes, leaves, surfedges and edges are smaller with SOLIDHINT and BOLIDHINT compared to the other two.

So, what do these results mean?
Not much. I think this texture is mostly applicable on terrain, and to be exact, ground terrain made out of quads and/or triangular prisms. I haven't tested this yet on tetrahedra. I don't think it should be used for walls (cliff sides, vertical terrain sides etc.) because the player can get kinda wedged into an edge. But those should be CLIPped to simplify their collision anyway.

slams table
Model data CAN be written to! :3

After grabbing a studiohdr_t pointer (header in the example code), we can access the bodygroup, then the submodel of said bodygroup, and then the vertices of the submodel.

void StudioExampleStuff( studiohdr_t* header, mstudiobodyparts_t* bodygroup, mstudiomodel_t* submodel, Vector& vert, int cntr )
{
    static float flWave = 0.0;

    flWave += M_PI/240.0;

    if ( flWave > M_PI )
        flWave *= -1;

    if ( header )
    {
        bodygroup = (mstudiobodyparts_t*)((byte*)header + header->bodypartindex);

        if ( bodygroup )
        {
            submodel = (mstudiomodel_t*)((byte*)header + bodygroup->modelindex);

            if ( submodel )
            {
                for ( int i = 0; i < submodel->numverts; i++ )
                {
                    float* vertFl = (float*)((byte*)header + submodel->vertindex) + i;

                    float indexWave = (float)i / (float)submodel->numverts;
                    float indexOffset = (indexWave * 2.0) - 1.0;
                    indexWave *= 4.0 * M_PI;

                    vertFl[ 2 ] += sin(flWave + indexWave) * 0.004 * (indexOffset*2.0) + sin(flWave*4.0 + indexWave)*0.01;
                }
            }
        }
    }
}

So, they aren't read-only.

Video: https://i.imgur.com/kYnorpP.mp4

This definitely opens up some new opportunities, such as having custom waves without the need of any vertex shaders (that alone would require doing... stuff to the renderer).
Of course, keep in mind that when one model is changed, it is common for all entities using that model. Meaning if you have 40 entities using models/something.mdl and you change the vertices on it, you will change it on them all. Maybe some mods will have a use for this, where for example, if the player damages one object and its vertices bend, it affects basically every other object in the map.

Imagine literally melting a Gargantua tho'. It'd look hilarious. Deforming terrain, yet again, except this time in the form of a 3D skybox. Anything can be done, really. Unfortunately, depending on the complexity of the model, it can potentially cause performance issues.

In other news, I made a small change to BSP and VIS. Now, BSP outputs two .prt files.
mapname.prt
mapname_viscache.prt

An example mapname.prt looks like this:

539
1330
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)

mapname_viscache.prt:

539
1330
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
4 0 123 (28672.000000 12288.000000 0.000000) (32768.000000 12288.000000 0.000000) (32768.000000 12288.000000 16384.000000) (28672.000000 12288.000000 16384.000000)
4 1 122 (28672.000000 12288.000000 16384.000000) (28672.000000 12288.000000 20480.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 12288.000000 16384.000000)
4 1 28 (20480.000000 12288.000000 16384.000000) (20480.000000 12288.000000 20480.000000) (20480.000000 28672.000000 20480.000000) (20480.000000 28672.000000 16384.000000)
4 2 10 (26624.000000 28672.000000 1419.636364) (26624.000000 28672.000000 16384.000000) (26624.000000 30208.000000 16384.000000) (26624.000000 30208.000000 1280.000000)

539 stands for the number of visleaves, 1330 is the number of visportals.
The 1s are the result of a recursive function called WriteLeafCount_r, so basically, each node writes its number of visleaves.
The problem is, map editors like J.A.C.K., or generally any map-related program like Crafty, not read the .prt file correctly because of these 1s.
Normally, you'd have to use a text editor and remove these 1s, but hopefully, once I release my compilers, there will be no need for that.

An optimisation could be made. Instead of mapname.prt and mapname_viscache.prt having the same content apart from the 1s, mapname_viscache.prt can ONLY have the 1s, and later on, VIS will read both and 'merge' the data.
Alternatively, per seedee's suggestion, VIS can just delete the 1s from mapname.prt once it's done its job.

Either way, this should speed up the workflow a little bit, at least for people who wanna optimise their maps and preview the effects their HINT brushes have on the portals.

Here's a video of it in action: https://i.imgur.com/N7al7uJ.mp4

Ah of course! And the same should work for sprites as well.

And yeah it doesn't look like client.dll has any per-entity callback (looks like they're mostly per-frame). Too bad but better than nothing.

Map textures can be modified too. So that's a good thing. uwu

video
video 2

Software water effect in OpenGL, anyone?

Ooooh yes please.

Oooh, I concur

Definitely gonna have to finish that feature one day. Right now it only supports this on a single texture.
It's gonna affect any texture beginning with water or !, but I'm thinking of potential applications of this elsewhere too.

Since this works by modifying the texture's pixels in real-time (NOT affecting the actual WAD file itself), I think we can accomplish real-time moss growth, and potentially many other things!

Nice work.
I guess that you are limited to the same size texture though? I assume the file is memory-mapped and that overwriting the texture data with a larger texture would overwrite the data that follows it?

I could just create new textures, probably.
What textures have is an "OpenGL texture number". So by creating a new texture, we're creating a new texture number. Which means I can just do this:

GLint myNewTexture;
... // after some TGA parsing with DevIL and texture creation via gl functions
texture->gl_texturenum = myNewTexture;

As for resizing, i.e. updating the original texture, we'll see. I am definitely thinking of writing some tutorials about this.

This must use software scaling. That's what I meant. However, if UV coords have a range of 0.0 to 1.0, then I'm completely fine, I won't have to resize the texture or anything.

DevIL supports Targa too:

Truevision Targa - .tga
Tagged Image File Format - .tif
Gamecube Texture - .tpl
Unreal Texture - .utx
Quake 2 Texture - .wal
Valve Texture Format - .vtf

Oh, look at that, one can potentially implement Source texture support in a HL mod.
FreeImage looks good too, but I'll see about all that.

Ah right - didn't even think on playing with gl_texturenum
Looking at texture_t though I see offsets and paloffset which I guess give access to the texture data and palette but as I look now I'm not sure what the offsets are relative to - any ideas?

Also, one thing to keep in mind is, you're gonna need an updated header file for BSP models.
As for the offsets, I'll try to check these out this weekend.

Any luck figuring what they offset into?

I forgot I was gonna do that. Oops. Well, now is the weekend, so... time to see.

Any luck figuring this out? I poked around again and Mod_Extradata returns raw model data - maybe the offsets work on that point for .mdl files, but not sure about .bsp or .spr files.

offsets is a byte offset for each mipmap level: https://github.com/id-Software/Quake/blob/bf4ac424ce754894ac8f1dae6a3981954bc9852d/QW/client/model.c#L372-L381

paloffset is an index into a global array of palettes. The Software version uses it to render the images, the OpenGL version passes the palette data to glColorTableEXT.

The layout of texture_t in Software mode seems to be quite different from what's in the SDK, so i wouldn't rely on that type for anything. The type also differs between Software and OpenGL modes.

@tschumann I haven't even touched it, sadly. I must've forgotten again.
Anyway I am gonna take a look at it today. uwu

@Solo
Thank you very much for the info! I'm planning to poke around just in OpenGL mode, as the experimental branch is already crashing in Software mode, LOL.

Hm, and it doesn't look like the global palette array is exposed to client.dll - in that linked code it looks like raw pixels get copied right after the texture_t for some reason? Possibly that still happens in GoldSource?

I wasn't planning on playing with this in software mode but I assume the GLQuake texture_t is the same as what is in GoldSource though?

Maybe it isn't possible to modify the raw texture data at a runtime - IEngineStudio.StudioSetupSkin looked promising but it looks like it only loads the texture (https://www.mail-archive.com/search?l=hlcoders@list.valvesoftware.com&q=subject:%22%5C%5Bhlcoders%5C%5D+p%5C%2Fw+model+skins%22&o=newest&f=1) so I'm not sure why it's even exported to client code.

My assumption is that even if you modify that texture data, you won't see any changes.
texture_t isn't exactly the same as in GoldSrc IIRC. There is a gl_texturenum for detail textures AFAIK but you need an updated com_model.h for that. uwu

Yeah I see references to an mextrasurf_s but that looks like Xash3D stuff - not sure how regular GoldSource handles it.

Oh nah, I'm not talking about mextrasurf_s but rather this:

typedef struct texture_s
{
    char                name[16];
    unsigned int        width, height;
    int                    gl_texturenum;
    struct msurface_s    *texturechain;        // for gl_texsort drawing
    int                    anim_total;            // total tenths in sequence ( 0 = no)
    int                    anim_min, anim_max;    // time for this frame min <=time< max
    struct texture_s    *anim_next;    // in the animation sequence
    struct texture_s    *alternate_anims;    // bmodels in frame 1 use these
    unsigned short        fb_texturenum;        // auto-luma texturenum
    unsigned short        dt_texturenum;        // detail-texture binding
    struct mextrasurf_s    *lightchain;        // used for drawing spotlights
    unsigned int        unused[2];            // reserved
} texture_t;

Allegedly, this works just fine with vanilla GoldSrc. I found this texture_s version with gl_texturenum in it on accident, in a Russian tutorial about mirrors.
I wouldn't be surprised if I can get a reference to detail textures this way, too, because then I can just do gl_texturenum = dt_texturenum; or if that doesn't work, I grab the actual texture handled by gl_texturenum and replace it with the one from dt_texturenum using OpenGL commands. It'd be pretty interesting to experiment with these.

Hm, I might have to do some digging (though the offsets and paloffset have both gone missing?) - fb_texturenum was definitely Xash3D specific I thought anyway.
Too bad there is no proper vanilla updated com_model.h - the one that always gets shared around I think has an out of date decal_t at least.

Also, in model_t textures is a texture_t** - is this to deal with animated textures or something? I never noticed it before to give it any thought.

A small update on the current development status of UAS/ADM:
I've been a bit busy with Heffernan's "Delta City 2155" mod, but I should be back to this thingy next week.
Can't wait to do some more stuff about the FMOD implementation.