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

Created 1 year ago2019-01-16 00:46:21 UTC by Admer456 Admer456

Posted 1 month ago2020-02-16 08:51:30 UTC Post #343752
I think client entities are not read-only. Once the client receives all the data about the entity, then they should be able to write to them as they wish, without affecting entities on the server.

In hud_bench.cpp, I've seen something around line 750, where cl_entity_t's are getting modified. However, I'm not exactly sure how you meant "entities would be read-only".
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-02-29 05:49:28 UTC Post #343818
Oh I meant model_t.entities would be read only but a lot of the others should be modifiable.
Posted 1 month ago2020-02-29 16:42:10 UTC Post #343826
"entities would be read only but a lot of the others should be modifiable."
Yes, but what do you exactly mean by "entities"? cl_entity_t, sending the modified data back to the server etc.?

Anyway, I accidentally came across another little thing inside model_t:
char* entities;
Only worldspawn has this set, and apparently, it stores the whole entity lump of the BSP. So, that's cool. :3
Not that we can really use it for anything, but it's nice to know.
the image is a bit tall, so

Algorithm: (can be put in some of the HUD classes)
for ( int i = 0; i < 120; i++ )
{
    cl_entity_t *pEnt = gEngfuncs.GetEntityByIndex( i );

    // this doesn't guarantee that the entity exists or doesn't exist
    // but we needed something quick and dirty
    if ( (pEnt->curstate.origin != Vector(0,0,0)) || i == 0 )
    {
        if ( pEnt->model )
            gEngfuncs.Con_Printf( "\nEntindex %i - model->entities %s", i, pEnt->model->entities);
        else
            gEngfuncs.Con_Printf( "\nEntindex %i - no model here", i );
    }
    else
    {
        gEngfuncs.Con_Printf( "\nEntindex %i - no entity here", i );
    }
}
And it looks like vertex manipulation just isn't gonna work on studio models.
User posted image
Can't even read, let alone write to it, LOL. It looks like model_t only provides all data for brush models. For sprites and studio models, it doesn't do much.

In other news, yesterday I made a 65k x 65k units test map.
bigterrain2.bsp - J.A.C.K. could use a farther back clipping plane herebigterrain2.bsp - J.A.C.K. could use a farther back clipping plane here
User posted image
The two large maps before this one were 16k x 16k and 32k x 32k respectively.
bigterrain1.bsp - first large test mapbigterrain1.bsp - first large test map
airveh1.bsp - air vehicle testing mapairveh1.bsp - air vehicle testing map
This bigger size required a slight change in the map compilers (specifically HLCSG), so that the BOGUS_RANGE macro refers to g_iMaxEntityRange instead of a hardcoded value.
g_iMaxEntityRange is, of course, set by the -maxentrange param in HLCSG.

In spring or summer, I'm gonna test a 131k x 131k map, and then I'm done with testing large maps.

I'm very curious to see how feasible large maps will be. Because I'm pretty sure mappers can cram a lot into them even on that scale. :walter:
This test map ate 20% clipnodes (14% with -nohull2) and almost 10% AllocBlock. The other lumps were below 5%.
Considering the fact that this is basically a big box map, this could just be one of the worst possible scenarios, and with enough CLIPping etc., I'm pretty sure making large GoldSrc maps is very doable.
I'll talk about this mod's open map design in one of the future posts.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 1 month ago2020-03-01 05:07:23 UTC Post #343833
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.
Posted 1 month ago2020-03-01 08:38:00 UTC Post #343834
"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. :walter:

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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 weeks ago2020-03-05 18:38:27 UTC Post #343856
Say hello to BOLIDHINT, our new tool texture family member!Say hello to BOLIDHINT, our new tool texture family member!
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.
User posted image
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. :thebox:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 4 weeks ago2020-03-07 06:16:45 UTC Post #343863
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.
Posted 4 weeks ago2020-03-07 12:39:25 UTC Post #343864
It seems that BOLIDHINT works. :D

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:
Reference - approximately 130 facesReference - approximately 130 faces
NULL - 592 wpolys, bad subdivisionNULL - 592 wpolys, bad subdivision
BEVEL - 594* wpolys, bad subdivisionBEVEL - 594* wpolys, bad subdivision
SOLIDHINT - 446 wpolys, good subdivisionSOLIDHINT - 446 wpolys, good subdivision
BOLIDHINT - 446 wpolys, good subdivisionBOLIDHINT - 446 wpolys, good subdivision
*594, probably because one of my view angles was just 1 or 2° off, but it'd be 592 otherwise. :P

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.
Admer456 Admer456If it ain't broken, don't fox it!
Posted 2 weeks ago2020-03-20 20:54:03 UTC Post #343934
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
Admer456 Admer456If it ain't broken, don't fox it!
Posted 6 days ago2020-03-29 07:12:58 UTC Post #343988
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.
Posted 4 days ago2020-03-31 11:37:46 UTC Post #343994
Map textures can be modified too. So that's a good thing. uwu

video
video 2

Software water effect in OpenGL, anyone? :walter:
Admer456 Admer456If it ain't broken, don't fox it!
Posted 3 days ago2020-03-31 23:38:23 UTC Post #343995
Ooooh yes please.
Rimrook RimrookGoldsource Guru
Posted 3 days ago2020-04-01 14:03:11 UTC Post #343999
Oooh, I concur
UrbaNebula UrbaNebulaGoldSourcerer
Posted 3 days ago2020-04-01 14:13:34 UTC Post #344000
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!
Admer456 Admer456If it ain't broken, don't fox it!
You must be logged in to post a response.