Looping square map

[D-Meat]

Hello Quake 3 world !

After having more or less successfully implemented a 6dof camera movement (mouse only at the moment), I'm moving on to a second big feature on my Lutfrauser adaptation process : A "looping" environnment.

What I want is a basic square map, of a given size. When you approach a size, you can continuously see the "other side" of the map drawing in front of you. when you or any entity hits the side, it gests teleported on the other without any effect, at the corresponding position with the same speed. The repetition should appear seamless.

For the moment, I'm focusing on the graphical part.
We all know that idTech3 is capable of drawing portals (and mirrors, that are portals with an inverted matrix applied). By default, you can't see a portal through another portal, but it seems that it's not a big problem to solve.

But on my situation things get tricky : with a FOV of 90°, you can see up to 3 times the original map throuth "portal views" :

The red sign is the real player, the green signs are the "virtual" cameras required to see beyond the edge of the square map seamlessly.

So, how to do that ?
I think I'll need a way to position my "virtual" / complementary cameras at the right place. For that, I'll need to store somewhere the size of my square map, from which can compute the position of the camera outside the map to get the missing parts. The camera angles remain the same.
Then, I should start drawing the A part, then B or C, and finally the "real" part.

Hey, this sounds simple. Now let's look at the code. Ah, ok, for the moment I don't understand much of all this.

Concretely, I found a generic functions that draws the scene through some parameters :

Code: Select all

void R_RenderView (viewParms_t *parms)

I'm sure at some point that will come in handy.

But for the moment I a lost in some earlier planning questions :
- I will still load a BSP with the square floor (that will be ocean in the end), with some "portal" surface walls all around it, and maybe a new WorldSpawn proprety like for example "MapSize", that with a value of 1024 would mean a square of 2048 units of side length (the north east corner would be at 1024:1024, with that parameter it is possible to always have a square shape and easely have the X;Y coordinates of the corners). Ok, now how do I add a proprety to a worldspawn ? How can I make this variable readable by bith client and server and renderer ?
- Should I add a new "portal" surface type ? For the moment, idTech 3 has some "tags" that defines some surfaces as Portals and Mirrors. I'm afraid the "Portal" surface is "locked" with the system of a Portal Surface and Portal Camera. If I want to add some new "type", how should I proceed ?

Always, if anyone here has already worked on that subject, or knows someone, or knows a place with some documentation about the rendrering of portals in that engine, this would be really great ! For the moment, I'm juste reading some code, things get a bit more clear everyday, but any help will make me learn faster

Thanks for reading !

[UglyFoot]

I tried to do the same for some time but I didn't finish. I do not think you have to calculate the positions of the cameras, the game calculates it from the portal_camera and the position relative to the surface of the portal. To check this you can create a test map, I used this shader to avoid the fog that appears when you move away from the portal.

Code: Select all

textures/proves/portal
{
	surfaceparm nolightmap
	surfaceparm noimpact
	portal
	{
		map textures/sfx/portalfog.tga
		blendfunc blend
		depthWrite
		alphaGen portal 512
		alphaGen const  0.0
	}
}

[Eraser]

Not sure what you're trying to accomplish? Is each square room sealed off by walls and can you move from one room to another only by a hole in the wall? If that's the case, then maybe it's easier to simply duplicate brush geometry in memory for the parts that the player can see, and actually have the player physically move there? Not sure how easy or hard that would be, but using portal cameras and teleportation to achieve this sounds a lot harder to implement. In fact, it sounds almost impossible, because what happens to all the other visible entities in the game, like enemies? They all would need to be repositioned relative to your new location as well?

[D-Meat]

Thanks UglyFoot for your shader ! I'll try it out

Not sure what you're trying to accomplish? Is each square room sealed off by walls and can you move from one room to another only by a hole in the wall? If that's the case, then maybe it's easier to simply duplicate brush geometry in memory for the parts that the player can see, and actually have the player physically move there? Not sure how easy or hard that would be, but using portal cameras and teleportation to achieve this sounds a lot harder to implement. In fact, it sounds almost impossible, because what happens to all the other visible entities in the game, like enemies? They all would need to be repositioned relative to your new location as well?

Ah sorry, my little sketch was not so clear. The central square is the "real" one, and the squares around represent actually exactly the same, but viewed from another point ! it shows the "illusion" that I'm trying to accomplish using portals. So no game entities need to be re-positionned, I think.

As I already planned, I'll test out the "R_RenderScene" function, and if it works, I'll try to pass the "mapSize" parameter I talked about and try a 1 dimension looping map.

What you're talking about shows a problem I'll have to solve when the visual part is done : my enemies won't be AAS driven (they will work more like guided rockets, in a way), and I'll have to get them to go in the direction that's the closest to the player, considering the looping map. for the moment, I can identify a serie of "ifs" to do that, but if there are more than 100 enemy planes, that might get quite heavy ^^

I hope I'll have some time to code after I come back from Japan !

[UglyFoot]

Another problem is that when an enemy explodes you will see it repeated many times.

[D-Meat]

Hi there !

I came back from Japan about 6 or 7 weeks ago now (oh you can ckeck photos from there here : http://third-impact-onigiri.blogspot.fr/), I'm looking for a job, and in the meantime, I'm getting creative at various things, and this includes me trying to make things with that idTech 3 engine.

So back to topic
I could accomplish the beginning of what I want to achieve ! Check this video :
http://www.youtube.com/watch?v=jviz8z63Dn8

As I say in the description of the video, I have 2 problems to solve :
- make this dynamic : the program will chose which view to render according to the direction the player is looking at
- make this looking good : the hard part ! I would like the rendered views to fade away and blend with the sky, but for the moments, it's a bit hard.

Always, if you allready worked on stuff like this or know anything that could help, it would be gratly appreciated !

[D-Meat]

So after thinking around, I thought that it will be impossible to achieve some nice fading in the distance effect with the technique I brought up previsously - For example, with the actual "fixed portal" solution, the fog can't be rendered well (it "adds" itself in each rendrering pass, and the transition beween map "sectors" is clearly visible, even with very low values.



So, I decided to change radically the approach to the problem :
What I'd like to do now is to add visual Instances of the game entities at given positions. I'm currently searching around, reading in cgame/cg_ents.c, but I don't know where I should look : in the renderer part or in the game / spawn entities part ?

Please note that I'd like to do that without adding new "real" entities to the entity list.



The map / environment itself will be a single BSP with some fog.
Oh, and of course, the "ground" (it will be some ocean in the final state) textures will be mapped so that at the corners there is no visible cut when the player will jump from one edge to the other.

[D-Meat]

Thanks to the people who brought me on the right way, I finally achieved what I was aiming to : a "simple" system that moves entities from their origin to the correspondant point outside the gameplay square !

Check this :
http://www.youtube.com/watch?v=WTdzw8E9Im0

Now I have to make a system that can handle all situations, because now there are some situations where the moving isn't done right

[Eraser]

Nice work!

[CZghost]

Wish the endless stairs live!

[UglyFoot]

Congratulations for getting this far.

What situations do you mean?

[D-Meat]

What situations do you mean?

Well, the system I have now is very fast and at some point quite easy to understand, but it only works well in the angles of the "gameplay area" square. If you look in an X or Y axis direction (vector 1;0;0 for example), moving slightly from left to right will make some entities (here ammo packs) pop up in front of you. I ask information about 3 vectors and I store boolean results :
- player / camera position : is it > 0 in the X axis or not ? is it > 0 in the Y axis or not ?
- player / camera forward vector : is it > 0 in the X axis or not ? is it > 0 in the Y axis or not ?
- entity position : is it > 0 in the X axis or not ? is it > 0 in the Y axis or not ?
With the result of these questions I created a table of all the possible results (in an image software) to point out the cases where nothing has to be done, or where the entity has to be moved North, north-east, east, south east, south, south west, west, and north west. From that I created a switch that goes to the right answer. I can post the code here if you want.

I'm still thinking about it now, and I hope I can come up with a system that could work well in a fov 180 case (which is the total extreme case, and so it's compatible with all other inferior Fovs ). For the moment I'm thinking of a way of testing the visibility of the entity by testing the angle formed by the camera forward vector and the vector created from camera origin to the entity origin. If the vector is > to 90°, then the entity is not seen. The part I have to solve now is to find out where to move the entity according to the forward vector of the camera

Oh and I have a question : The game Turok Dinosaur Hunter is very famous for its abuse of fog. And actually, the fog system in this 1997 game is more flexible than Quake 3's : the fog can start and and at any given distance, but in Quake 3, only the "opaque" distance can be specified. I'd like to change that to do tests because I'd like to have a zone in the view field where there is no fog at all, and after that the rest fades out. This is more low-level / rendering engine stuff, I know. I'll look into it

[UglyFoot]

deleted

[UglyFoot]

Hi, how it's going?

Recently I remembered this post and I thought I didn't explain well, plus there are mistakes so I started to program a solution based on what I explained and it worked. Surely you must have done it yourself but if not, I leave here the code. To make it work you must put it at the beginning of cg_ents.c.

Code: Select all

#define	SIDE_LEN 512

void CG_DuplicateEntity(centity_t *cent, void (* func)(centity_t*)) {
	int				i;
	vec3_t			initial_origin;
	vec3_t			trans_vecs[9];
	VectorSet(trans_vecs[0], 0, 0, 0);
	VectorSet(trans_vecs[1], SIDE_LEN, 0, 0);
	VectorSet(trans_vecs[2], SIDE_LEN, SIDE_LEN, 0);
	VectorSet(trans_vecs[3], 0, SIDE_LEN, 0);
	VectorSet(trans_vecs[4], -SIDE_LEN, SIDE_LEN, 0);
	VectorSet(trans_vecs[5], -SIDE_LEN, 0, 0);
	VectorSet(trans_vecs[6], -SIDE_LEN, -SIDE_LEN, 0);
	VectorSet(trans_vecs[7], 0, -SIDE_LEN, 0);
	VectorSet(trans_vecs[8], SIDE_LEN, -SIDE_LEN, 0);

	VectorCopy(cent->lerpOrigin, initial_origin);

	for(i=0; i<9; i++) {
		VectorAdd(cent->lerpOrigin, trans_vecs[i], cent->lerpOrigin); 
		func(cent);
		VectorCopy(initial_origin, cent->lerpOrigin);
	}
}

This function duplicates 8 times an entity. To use it you must go to CG_AddCEntity and for example change CG_Item (cent) to CG_DuplicateEntity (cent, CG_Item). SIDE_LEN is (obviously) the side length of the square on which the player moves.

Hope that helps, but it can be improved. For example translational vectors should be constants to make the function faster.

[D-Meat]

Thanks for replying !

Even if I was not posting, I could make some good advance on the subject I now have a system that works quite well ! I'll make a video one of these days

The code chunk you posted is a good summary of the logic I have behind the code ! Except I didn't manage to duplicate the entities ... So my system just moves existing entities

I have 2 phases : One where I find out the "sides" of the gameplay area the player is looking at, and then I use that information to move the wanted entities (only ammo boxes for the moment) to the required position.

In order to do that, I added some variables in the cg structure, a vec3_t table that has the map "bounds", and a slot where the "loop direction" is written in a new typedef enum

I am now adding the "teleport" feature that will move things from one side to another when they hit the bounds of the game area. I have 2 questions about that :
- How can I make a variable "global" ? I mean, how to make it accessible in the client chapter, server chapter, game chapter, cgame chapter, or even renderer chapter ? For example, I have an int variable that represents the map "radius" (gameplay area side / 2), I use it at the moment in cgame for the looping map effect, but for the teleportation, I need it in the game project !
- Is there a tutorial on how to get teleporters to teleport rockets / plasma for example ? from that I could do coo things

Thanks in advance ! The video is coming

[Sheepsquatch]

@D-Meat,

Try putting the variables in q_shared.h, should have access in all the modules. Good luck.

[UglyFoot]

I guess you can declare a variable like Sheepsquatch said but as I see it if you use a pair of trigger_teleporter and misc_teleporter_dest (or something like that) for each side for teleporting, the game module won't need to know the radius. Obviously they can't be exactly those entities, they need to be modified, at least trigger_teleporter.
Better than declaring a global variable would be defining a constant with #define.

To teleport rockets, the same. I think you have to create an entity type based on trigger_teleporter and modify it for that. I do not know if there is a tutorial, maybe at http://www.quake3hut.co.uk/q3coding/, but if you want to do it yourself take a look at g_trigger.c.

[D-Meat]

I guess you can declare a variable like Sheepsquatch said but as I see it if you use a pair of trigger_teleporter and misc_teleporter_dest (or something like that) for each side for teleporting, the game module won't need to know the radius. Obviously they can't be exactly those entities, they need to be modified, at least trigger_teleporter.
Better than declaring a global variable would be defining a constant with #define.

Currently, I'm modifying the original trigger_teleport, by adding spawnflags (so that the teleporter works normally in normal maps ). I just need that variable because I don't know yet what my final "map radius" will be, and actually there might be game modes with different map sizes, so that value might need to be updated - It can't be constant I'll try to add it in q_shared.c !

To teleport rockets, the same. I think you have to create an entity type based on trigger_teleporter and modify it for that. I do not know if there is a tutorial, maybe at http://www.quake3hut.co.uk/q3coding/, but if you want to do it yourself take a look at g_trigger.c.

Thanks for the link ! I just found a "plasma teleporter" tutorial that will do the trick !

[D-Meat]

Coming back from the frost of templar-land ...

CHECK THIS : http://youtu.be/ACXKzO0K4n8

So, the effect was achieved. What's good is that the "map radius" is written as a key/value pair in the map's worldspawn, and then copied to 2 Cvars in the game and client game modules.

I struggled a lot when trying to understand the "syscall" functions, hoping to add one to pass the value from "game" to "cgame" ... And then, last night, I used the "Trap_Cvar_Set" function, and it did not olny work for "g_loopsize", but also for "cg_loopsize" ! I'm saved.

fun-fact : on the video, there is no visible transition when the player gets teleported from one side to another. Ingame, there is always one frame of "hyperspace", that is clearly noticeable. Can someone document me about that "hyperspace" concept ? Should I code my own teleport trigger to avoid it ?

[UglyFoot]

No, I don't think you have to create your own trigger. cg.hyperspace is true when you touch a trigger_teleport. As I see it there's two ways to do this:
- If you want keep the original trigger_teleport but with a flag for your mod you will have to detect that flag from the client side and make cg.hyperspace true or false.
- Another way to do it if you don't want to use the original trigger_teleport is simply comment the line that makes cg.hyperspace true.

This is done in the cg_predict.c file. Just in case you don't know (hardly) your editor should have some feature to search in all files of the project, which is useful in this cases.

[D-Meat]

Thanks for your quick reply !

No, I don't think you have to create your own trigger. cg.hyperspace is true when you touch a trigger_teleport. As I see it there's two ways to do this:
- If you want keep the original trigger_teleport but with a flag for your mod you will have to detect that flag from the client side and make cg.hyperspace true or false.
- Another way to do it if you don't want to use the original trigger_teleport is simply comment the line that makes cg.hyperspace true.This is done in the cg_predict.c file.

Thanks ! I'll try this out

Just in case you don't know (hardly) your editor should have some feature to search in all files of the project, which is useful in this cases.

Yeah, I use it all the time

[D-Meat]

No, I don't think you have to create your own trigger. cg.hyperspace is true when you touch a trigger_teleport. As I see it there's two ways to do this:
- If you want keep the original trigger_teleport but with a flag for your mod you will have to detect that flag from the client side and make cg.hyperspace true or false.
- Another way to do it if you don't want to use the original trigger_teleport is simply comment the line that makes cg.hyperspace true.This is done in the cg_predict.c file.

Thanks ! I'll try this out

It works ! That was surprisingly easy

Now I'm moving on to the player / plane control, heading to game/pmove.c. Maybe I'll start a new topic ! Or create a topic dedicated to my prototype project

[UglyFoot]

Alright, we'll see how it turns out

[Bacon]

Reminds me of: http://www.youtube.com/watch?v=pxJK37jZPRc

[D-Meat]

Reminds me of: http://www.youtube.com/watch?v=pxJK37jZPRc

Aliens versus Predator style I'm curious to see how this was coded