Forum

RANT: What's wrong with CSQC

Discuss CSQC related programming.

Moderator: InsideQC Admins

Re: RANT: What's wrong with CSQC

Postby ceriux » Sat Jul 05, 2014 8:48 pm

how would you use this model viewer?
User avatar
ceriux
 
Posts: 2223
Joined: Sat Sep 06, 2008 3:30 pm
Location: Indiana, USA

Re: RANT: What's wrong with CSQC

Postby Spike » Sat Jul 05, 2014 10:33 pm

the lack of a space was intentional.
modelview progs/foo.iqm
or whatever.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: RANT: What's wrong with CSQC

Postby LordHavoc » Sun Jul 06, 2014 5:59 pm

Spike wrote:the predraw method (and by method, I mean function stored in a field) is invoked by the addentities function (just before the engine implicitly calls addentity on the entity for you - note that in FTE you can inhibit the engine's auto addentity call by returning TRUE, giving you a chance to revert temporary field changes or whatever).
because addentities is called each frame, the predraw function is also called each frame too, for each entity.
this gives you a chance to edit the fields to interpolate or extrapolate the entity as you feel fit before it is submitted to the renderer, with exact timing info and stuff.
naturally, you can use it as a second think function, but often you'll get smoother results by using it exclusively instead of .think.


It's worth noting that if you do multiple views, you'll likely be calling addentities more than once per frame, and should probably set frametime to 0 after the first time (it's also important to make sure predraw functions can handle frametime == 0 in some harmless way).

This also applies in the case of r_stereo/vid_stereobuffer rendering in darkplaces unfortunately (where CSQC is invoked twice).

Spike wrote:I'll make a mental note to actually test the example when I've more time on my hands, I don't see any obvious reason why it wouldn't work. I was messing with skeletal objects yesterday so I know skel_build works in that mod at least.
be aware that a fixed lerpfrac 0.5 will blend two separate animations in a way that you might percieve as buggy. I believe I wrote it that way to invoke some curiosity. fte now has a 'modelviewer' command that you can use to check what the engine sees in the model, in terms of frames and framegroups and skins and bones and stuff. its rudimentary but gets the job done. note that DP doesn't necessarily see the same thing for all model formats - fte strictly sees what is in the model, while in my experience DP has a tendancy of unpacking framegroups and throwing away the animations.


DP only unpacks Unreal Engine .psk models (or more specifically the accompanying .psa file), it does not unpack any other format that supports internal framegroups (respectively .mdl, .zym, .iqm). I'd like to get rid of the .psa unpacking for consistency but Transfusion was using that model format in some beta release or something I think, so I haven't touched it - it also seems that no one else uses that model format anyway.
LordHavoc
 
Posts: 322
Joined: Fri Nov 05, 2004 3:12 am
Location: western Oregon, USA

Re: RANT: What's wrong with CSQC

Postby Nahuel » Sun Jul 06, 2014 8:58 pm

LordHavoc wrote: I haven't touched it - it also seems that no one else uses that model format anyway.

maybe its weird but I use psk models for props, casings, gibs etc (not animated models) instead md3 or mdl, this is for the small size and because the iqm exporter of neosis doesn´t work with darkplaces.
hi, I am nahuel, I love quake and qc.
User avatar
Nahuel
 
Posts: 485
Joined: Wed Jan 12, 2011 8:42 pm
Location: mar del plata

Re: RANT: What's wrong with CSQC

Postby Spike » Sun Jul 06, 2014 11:48 pm

electro was using psk models a while back, he said he found them easier to create (wasn't a DP project though, so they were all animated properly).
there's a psk shambler model around too, unfortunately it only has one framegroup in it.
either way, you can fix it with a .framegroups file so there is at least a path for backwards compatibility. any old/buggy models can be fixed up by almost anyone with a suitable example of how to do it.
psk requires more work to load, so if you have high vertex counts, iqm is definitely the better choice. this assumes you've got a working exporter in your editor that doesn't require lots of tweaking for each and every export, anyway. having to depend on an external tool like neosis is a bit crap really, so yeah, psk is just easier, assuming everything gets treated the same by the engine anyway.

also, model formats is a bit off-topic, this topic is meant to be about all the fuckups in csqc, not other junk in the engine.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: RANT: What's wrong with CSQC

Postby Baker » Mon Jul 07, 2014 1:18 am

The best and scariest Shambler I have ever seen in Quake is a psk.

http://quakeone.com/forums/quake-mod-re ... mbler.html
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Baker
 
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: RANT: What's wrong with CSQC

Postby toneddu2000 » Mon Jul 07, 2014 1:43 pm

Nahuel wrote:maybe its weird but I use psk models for props, casings, gibs etc (not animated models) instead md3 or mdl, this is for the small size and because the iqm exporter of neosis doesn´t work with darkplaces.
Maybe, if you found out how to use csqc animated models, this community would be very grateful to know how! ;)

@Spike, thanks for the clarification on .predraw method but :
naturally, you can use it as a second think function, but often you'll get smoother results by using it exclusively instead of .think.
Wait!You mean I can use think in csqc?!?

Spike wrote: I was messing with skeletal objects yesterday so I know skel_build works in that mod at least.
Yeah, I know skel_build works flawlessy (I can debug before and after skel_build is applied and engine detects the new skeleton).
The problem is animating some entity that is not a player.
For example an npc. Imagine a windmill, with the blades rotating with animation data or via code. I cannot reach that milestone.
But, of course, it depends on my limited knowledge of the issue
I'd like only to find a npc animated example in csqc(FTE or DP, is not a problem) :)
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: RANT: What's wrong with CSQC

Postby goldenboy » Mon Jul 07, 2014 2:12 pm

Yeah, you can use .think in csqc.
User avatar
goldenboy
 
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel

Re: RANT: What's wrong with CSQC

Postby toneddu2000 » Mon Jul 07, 2014 7:51 pm

ah ok thanks gb. So can I use most of the SSQC constructs even in CSQC? For example all the fields like .solid, .movetype, etc?
toneddu2000
 
Posts: 1315
Joined: Tue Feb 24, 2009 4:39 pm
Location: Italy

Re: RANT: What's wrong with CSQC

Postby goldenboy » Mon Jul 07, 2014 8:21 pm

I haven't personally used those yet, but I'm pretty sure you can. Try it! For a definitive answer about what you can and can't do with entities in CSQC, Spike or LH will be needed though.
User avatar
goldenboy
 
Posts: 924
Joined: Fri Sep 05, 2008 11:04 pm
Location: Kiel

Re: RANT: What's wrong with CSQC

Postby Spike » Mon Jul 07, 2014 8:54 pm

.solid works in both engines. tracelines will just work as you'd expect. afaik this should work fine in both engines.
.movetype is more complex. it doesn't do anything at all in dp. in fte, you can configure various different engine behaviours via a global (the name of which currently escapes my mind). with fteextensions.qc included, this global has the value 2, which gives csqc the same physics as ssqc has. a value of 1 will vaugely emulate dp. a value of 0 will disable all movetypes (and unfortunately also .think too, as was intended in the original spec, as it is dependant upon movetypes).

hud-only engine implementations of qc might not even support traceline/tracebox etc, in which case all of these are just dead fields as far as the engine is concerned. for partial implementations its really the engine's choice as to what is omitted. :s
the original spec omitted movetypes because I wanted to be lazy - in an ideal world, sv_phys.c+sv_move.c would be shared between both modules in some way. explicitly allowing those to be omitted with the engine still considered 'complete' was intended to make engine uptake easier, or at least simpler anyway.
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Re: RANT: What's wrong with CSQC

Postby r00k » Tue Jul 08, 2014 6:46 am

LordHavoc wrote:Way back in 1999


I was dreamin' when I wrote this
Forgive me if it goes astray

LordHavoc wrote:vid_conwidth is a can of worms because it affects CSQC and menuqc, which I never intended (but Black and [515] apparently thought it should), there's no real opportunity to fix it now, even though I would like to, the only change I have planned is at some point adding a vid_conwidthauto cvar that computes it from the screen aspect ratio (vid_conheight*vid_width/vid_height/vid_pixelheight) and changing the default vid_conheight to 360 (to match the fact that most people have 16x9 monitors now).


Code: Select all
qboolean OnChange_vid_conwidth (cvar_t *var, char *string)
{   
   extern cvar_t vid_conwidth;

   vid.width = bound(320, (atoi(string)), vid_width.value);
   vid.width &= 0xfff8;// make it a multiple of eight
   Cvar_SetValue("vid_conwidth", vid.width);

   //pick a conheight that matches the correct aspect
   if ((vid_force_aspect_ratio.value)&&(!windowed))
      vid.height = (vid.width * vid.nativeaspect);//Set aspect to the monitor's native resolution not current mode.
   else
      vid.height = (vid.width * vid.aspect);

   vid.height = bound(200, vid.height, vid_height.value);
   
   Cvar_SetValue("vid_conheight", vid.height);

   conback->width = vid.conwidth = vid.width;
   conback->height = vid.conheight = vid.height;

   vid.recalc_refdef = 1;
   return true;
}
r00k
 
Posts: 1108
Joined: Sat Nov 13, 2004 10:39 pm

Re: RANT: What's wrong with CSQC

Postby Spike » Tue Jul 08, 2014 8:09 am

my opinion is that any csprogs.dat that reads the vid_conwidth cvar expecting it to affect anything but the console (which is outside the scope of csqc) is a buggy csprogs.dat.
read VF_SCREENVSIZE if you want to know the current virtual screen size (without depending on the width+height args), read VF_SCREENPSIZE if you want to know the current physical screen size.
@baker: note that these were not in csqcwinquake. you should probably consider adding them.

fte's cvar() builtin has a hack in it so that vid_conwidth and vid_conheight queries return the current virtual size, regardless of the cvars. this allows a 0 value to be used for auto or whatever.
cvar_string() doesn't contain this hack, so you can still use that to work around the work around.

any mod that uses vid_width+vid_height expecting it to be the physical width+height is buggy too (vid_restart may have failed, or simply not been used yet, or vid_mode overwrote it or whatever). DP requires it for certain things. this annoys me.

needing to depend on the engine recognising ANY specific cvar is a bad thing, imho. Oh, and its a pain to document... :P
Spike
 
Posts: 2883
Joined: Fri Nov 05, 2004 3:12 am
Location: UK

Previous

Return to CSQC Programming

Who is online

Users browsing this forum: No registered users and 1 guest