Strange origin problem with 3wave skins

[Cobalt]

Ok me and PrimalLove have confirmed this problem, but are clueless why its happening. Pretty much what we did was spawn a copy of the player model using csqc. This works well, and we can rescale it, move it with setorigin no problemo. Except - when we change skins in the player model past skin 0. Each increment in skin value causes the origin to "shift" , even though we are keeping the setorigin the same as usual. The shift seems to be incremental with each skin number, IE: Skin0 is ok. Skin 1 is about 2x origin to the right , skin2 is 3x the origin to the right and so on.


We have yet to confirm if it happens with other models with multiple skins in them, but so far the player.mdl with the (4) 3wave skins that came with 3wave CTF and CTFBOT+ will cause the shift...as well as the female cory model when she has those skins set.

I will try and post a screenshot , or Primallove may want to add one or add more details.

[PrimalLove]

I fixed this issue.

[wicked_lord]

Ok this is a simple fix.

Follow these steps below.

"
1.
2.
3.
4.
5.
6.
7.
99.
1,000.
1,000,000.

Ok keep following, almost done.....
"

[golden_boy]

it would be cool to know what the fix was.

[Cobalt]

He just stole more code - lol, just kidding.

Turns out he was using the wrong command to get the players origin. He will probably explain more in detal here.

it would be cool to know what the fix was.

[PrimalLove]

Cobalt was making some HUD additions with CSQC and wanted to do some things with colormap for the HUD images on screen. I suggested an idea of just placing the player model (mini version) on the screen that would just mirror your current skin/colormap automatically. I set up some basic code for him to play around with. I had first thought the best approach would just be to use a new scene but was less sure of the compatibility with this method in DP and also its less pleasing to the eye to have a new scene/screen showing only the model. I instead decided to use the renderflag RF_VIEWMODEL. This should allow the model to be viewable from the players prespective (only in first person) and should follow the player. This is in fact exactly what it does. But, my misunderstanding of how it accomplished this lead to this "bug". Before going much further it may be best to read up on what we are doing here. It is explained more or less here by Spike. At least on spawning the model in particular but does not touch on RF_VIEWMODEL which is what we are focusing on here.

This is the code I came up with for demostration purposes for Cobalt that caused the bug. Maybe you can catch the problem

// Called in CSQC_UpdateView
void PlayerDisplayDraw()
{
	[COLOR="Red"]setorigin(playerdisplay, getentityvec(player_localentnum, VF_ORIGIN)[/COLOR] + '15 12 0'); [COLOR="Yellow"]// Perhaps you can see the problem here.... :/[/COLOR]
	playerdisplay.angles_y += frametime * 256;  
	playerdisplay.lerpfrac -= frametime*10; [COLOR="Lime"]// So the animations are interpolated. This assumes quake's animation frame rate[/COLOR]
	while (playerdisplay.lerpfrac < 0)
	{
		playerdisplay.frame2 = playerdisplay.frame;
		playerdisplay.lerpfrac += 1;
		playerdisplay.frame += 1;
	}
        if (playerdisplay.frame >= PD_ENDFRAME)
	playerdisplay.frame = PD_STARTFRAME;
	[COLOR="Lime"]// So the model will match the player colormap[/COLOR]	
	float pants = getentity(player_localnum, E_PANTSCOLOR);
	float shirt = getentity(player_localnum, E_SHIRTCOLOR);
	playerdisplay.skin = getentity(player_localentnum, E_SKIN);
	playerdisplay.colormap = 1024 + pants + shirt*16;
}

[COLOR="lime"]// Called in CSQC_Init[/COLOR] [COLOR="Yellow"](Note I could have used a playerdisplay.predraw instead of just calling the update function in  CSQC_UpdateView and is probably better practice. [/COLOR]
void PlayerSpawn()
{
    playerdisplay = spawn();
    precache_model ("progs/player.mdl");
    setmodel(playerdisplay, "progs/player.mdl");
    playerdisplay.renderflags = RF_VIEWMODEL; [COLOR="Lime"]// So you can only see him in first person. And follows your position[/COLOR]
    playerdisplay.scale = .1; // Tiny Player :) 
    playerdisplay.alpha = 1;
    playerdisplay.drawmask = MASK_NORMAL;   
}

The fundamental misunderstanding was that I thought I needed to update its position. In speaking with Spike later on the matter, he informed me he did not believe DP correctly used RF_VIEWMODEL and thus should not work as I indicated it did. When he first saw the above code he assumed I had an additional setorigin elsewhere to keep the model within view. I originally had no idea RF_VIEWMODEL was not suppose to work correctly with DP. But back to my misunderstanding, I wrongly tried to use getentityvec with VF_ORIGIN.

VF_ORIGIN is meant to be used with setviewprop() or in DP perhaps more commonly known as R_SetView(). For reference, both are builtin # 303. At first, I used E_ORIGIN (GE_ORIGIN in FTE). This just placed the model in a position in the world and it of course never moves from that position. So I thought if I just use VF_ORIGIN it will be placed at my view origin and all will be good. In fact, I was actually calling E_SKIN (GE_SKIN in FTE). This is because VF_ORIGIN is not supported with getentityvec/getentity() it instead used E_SKINS. Because they both have the float value of 11. So because RF_VIEWMODEL works correctly I did not notice that I in fact did not even need to use getentityvec and what I had actually done here is call a vector to be returned of '0 0 0' (Because in most cases your .skin will be 0). So when you change your skin in game to self.skin 1 or more it is adding 1 to the X axis value. Thus making the model move away from the player view as you go up in skins. When I first approached Spike about it he did not catch the error but once I informed him that I was using VF_ORIGIN it all seemed to click. So in conclusion, apparently DP now does correctly use RF_VIEWMODEL. And I also figured out why changing skins changed the position of the model on screen. I of course felt very stupid at this point but it faded away after getting things right. So here is a better example of how to use it.


EDIT: Below was edited to take into account Spike's input. Thanks again, Spike. Now using player_localentnum for colormapping and predraw instead of adding anything to CSQC_UpdateView. Also removed redundant R_AddEntity because of use of MASK_NORMAL used for drawmask

entity playerdisplay; // mini player entity
#define PD_STARTFRAME 1 // Reference for starting running frame
#define PD_ENDFRAME 6 // Reference for ending running frame

//Animate and Spin it	
void PlayerDisplayDraw()
{

	playerdisplay.angles_y += frametime * 250;[COLOR="Lime"] // How fast you want him to spin.[/COLOR] 
	playerdisplay.lerpfrac -= frametime*10;
	while (playerdisplay.lerpfrac < 0)
	{
		playerdisplay.frame2 = playerdisplay.frame;
		playerdisplay.lerpfrac += 1;
		playerdisplay.frame += 1;
	}
       [COLOR="lime"] // Replay the running animation....[/COLOR]
        if (playerdisplay.frame >= PD_ENDFRAME)
	playerdisplay.frame = PD_STARTFRAME;		
	playerdisplay.skin = getentity(player_localentnum, E_SKIN); [COLOR="Lime"]// GE_SKIN in FTE[/COLOR]
	[COLOR="yellow"]playerdisplay.colormap = player_localentnum;[/COLOR]
}

//Spawn the Player Display
void PlayerSpawn()
{
        playerdisplay = spawn();
        precache_model ("progs/player.mdl");
	setorigin(playerdisplay, '15 14 -10'); [COLOR="Lime"]// Only need to set this once[/COLOR]
        setmodel(playerdisplay, "progs/player.mdl");
        playerdisplay.scale = .05; // Tiny Player :) 
	playerdisplay.alpha = 1;
	playerdisplay.renderflags = RF_VIEWMODEL | RF_DEPTHHACK;  
	playerdisplay.drawmask = MASK_NORMAL; 
        [COLOR="yellow"]playerdisplay.predraw = PlayerDisplayDraw;[/COLOR]
}


void CSQC_Init(void)
{

	[COLOR="Lime"]PlayerSpawn();[/COLOR]
}

This above code will give you something looking like this in game.



The model will spin around on screen and should match your current skin and and colormap.
(Note the colormap method assumes DP_ENT_CUSTOMCOLORMAP)

I believe Cobalt added support for the model to also match your current frames for animation purposes. Now the model will follow your movement as if it were part of your HUD. Giving your some 3d HUD possibilities using custom models and even animations using textures/skins with shaders. I rarely see things like this done. Perhaps someone will find this helpful. If any inaccuracies hopefully Spike or someone will mention so I am not giving any misleading or wrong information. Good day.

EDIT: A slightly better scaled version with a comparison with the grunt.




TL;DR
Fixed

[Spike]

float pants = getentity(player_localnum, E_PANTSCOLOR);
float shirt = getentity(player_localnum, E_SHIRTCOLOR);
playerdisplay.skin = getentity(player_localentnum, E_SKIN);

there's a typo or something in there.

note: playerdisplay.colormap = player_localentnum; saves some extra statements (plus works with rgb player colours if you ever run it in FTE).


also, drawmask+addentity means you redundantly get two copies of the entity.

using predraw to position your entity keeps the logic confined to the spawn function and avoids needing special code in your main update/draw function.

[PrimalLove]

Thanks Spike for the input. I made the changes to my post to reflect these suggestions. I did not realize you could just use player_localentnum. That actually fixed a bug I was experiencing with the colormapping.

[Cobalt]

@ Spike -

I touched base w PL on this , but was wondering your response.

Turns out when you are underwater and have r_waterwarp active, it makes this mini-me guy shift l-r. Turning it off stops his swing. Is there a way to isolate this ent from individual 3d type scenarios and more or less make it 2d in certain ways and still retain some or most of the 3d type features?

[talisa]

thats neat, having a lil 3D model of the player showing on the hud

.

is this a FTEqw only feature, 3D models on the hud?
or would this be possible in darkplaces as well?

if its possible in DP as well, it would be really cool to see a 3D hud which
uses the pickup models of weapons, powerups and keys as icons instead of 2D pictures <3

especially if the models would slowly rotate back and forth a bit every now and then

[PrimalLove]

@talisa

The code above will work with FTE or DP. A few minor changes need to be made to make it work with FTE (I put a few little notes about those cases in the code).

In FTE apparently you need to use RF_NOSHADOW to prevent the model from casting a shadow in the game. However from what I can see this is not the case with DP and can be ignored plus DP doesn't support RF_NOSHADOW anyway. If you place a model in the world wihtout using RF_VIEWMODEL in Dp this will be the case. So if you use it in FTE keep in mind that RF_NOSHADOW will be something you might want to include if using real time lighting. Also in FTE apparently model bobbing will apply as it does with weapon models. I have not seen this be the case in DP. The other thing to keep in mind is that the model will be effected by shadows and additional lighting within the level assuming realtime lighting. This would lead to some cases where your 3d hud would be dark just like the scene. I assume this can be over come with some clever shader use. FTE has a much better implementation of shader programs but DP should be able to provide a few solutions to this problem. I will release a small csqc scratch file so people can experiment with it. I'd love to see a cool 3d hud. My modeling skills are none existent. :/

@Cobalt - Perhaps Spike will be able to chime in but the way waterwarp works is it will warp the whole scene. Because the hud model is part of the scene I can see no practical way to isolate that behavior except perhaps by making an entirely new scene or maybe even possibly via a different drawmask?

[talisa]

DP supports some special flags, including one to models to make them appear fullbright
http://quakeone.com/forums/quake-mod...html#post97247

512 - Full Bright (model is full bright regardless of lighting)

i'd assume you could use that flag to circumvent the lighting of the scene?

also, perhaps you could just use the pickup models for on hud and put them on hud?
and use the self.scale command to make them the right size?

[Cobalt]

Interesting, I had 512 as an effect on him via csqc but after changing it to dimlight and brightlight, it did not seem to use any of the effects fields, so I stopped trying that route as a way of improving its lighting.

Im also in need of the model not reacting to shadows the world casts too - not sure if there was a flag someplace to do that or not, but yea Fullbright probbably would do that if it worked. Unless I am not coding it in right.....

[PrimalLove]

@talisa Yes you can indeed use EF_FULLBRIGHT as an added effect to the model. In the effects field. playerdisplay.effects = EF_FULLBRIGHT I don't like the look of it myself and think its possible to get a better effect with a shader but it will indeed do as desired.
Yes could use the pickup models (bsp, mdl, iqm) basically any model that Dp supports. Good idea tho. I might put together a small example 3d Hud using the current in game items for fun. Getting back to the modelflags, if they for whatever reason do not work with DP then shaders I have tested and they do indeed work. But I'll get more info from Spike. Spike also wrote an interesting 3d HUD example in his csqctest which is older but still relevant. In his example he makes a new scene to display the model. Its worth a read for those interested.

EDIT: Oops I forgot you asked about scale. Yes you can just use the scale field to give the model the correct size. For the player model I had to go pretty extreme.

@Cobalt

If you do not want a model to cast a shadow you can use EF_NOSHADOW on the model. It's used in the effects field.

[Cobalt]

Should be possible but like Im finding, they will have all the attributes a regular 3d model will have, such as the waterwarping problem I found, where R_waterwarp 1 will shift them around. Its possible theres other stuff like that where it would effect the model's appearance.

So far the lighting stuff w the effects like you said can tackle alot of the visible issues associated with light, and you can adjust to liking.

One thing I just thought of is sprites are 2d and therefore would bypass that problem I mentioned.

if its possible in DP as well, it would be really cool to see a 3D hud which
uses the pickup models of weapons, powerups and keys as icons instead of 2D pictures <3
especially if the models would slowly rotate back and forth a bit every now and then