Re: [hlcoders] Rescaling clipping problems (again!)
Michael A. Hobson wrote: > Try using the Studio Model Renderer API defined in cl_dll/r_studioint.h > > iEngineStudio.GetModelByIndex(1) is the world model corresponding > to the WorldSpawn entity and so forth. > > The return value is a pointer to struct model_s (defined in > common/com_model.h) Only problem there is no corresponding function on the server. (Is there?) Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
At 05:08 PM 2/21/2003 -0600, you wrote:
jc wrote:
> where abouts did you set the values (remembering that im not much more
> than a dumb ass n00b)
There are two ways that I know of, both in pm_shared, since I can't see
any other way to get a pointer to the engine's models array (Botman - I
tried GetModelPointer but it fails for brush models :) )
Try using the Studio Model Renderer API defined in cl_dll/r_studioint.h
iEngineStudio.GetModelByIndex(1) is the world model corresponding
to the WorldSpawn entity and so forth.
The return value is a pointer to struct model_s (defined in
common/com_model.h)
{OLD}Sneaky_Bastard!
Michael A. Hobson
icq:#2186709
emial: [EMAIL PROTECTED]
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
jc wrote:
> where abouts did you set the values (remembering that im not much more
> than a dumb ass n00b)
There are two ways that I know of, both in pm_shared, since I can't see
any other way to get a pointer to the engine's models array (Botman - I
tried GetModelPointer but it fails for brush models :) )
First, you can loop through all of the physents every frame and check
whether it's a BSP model and if so, set hulls.clip_mins and clip_maxs,like
so:
// My hullfile looks like this:
8 8 18
16 16 16
8 8 9
// I have my hull mins and maxs stored in global arrays like this:
#define SCALE_FACTOR 4.0
vec3_t VEC_HULL_MIN = { -16 / SCALE_FACTOR, -16 / SCALE_FACTOR, -36 /
SCALE_FACTOR };
vec3_t VEC_HULL_MAX = { 16 / SCALE_FACTOR, 16 / SCALE_FACTOR, 36 /
SCALE_FACTOR };
vec3_t VEC_DUCK_HULL_MIN = { -16 / SCALE_FACTOR, -16 / SCALE_FACTOR, -18 /
SCALE_FACTOR };
vec3_t VEC_DUCK_HULL_MAX = { 16 / SCALE_FACTOR, 16 / SCALE_FACTOR, 18 /
SCALE_FACTOR };
vec3_t VEC_LARGE_HULL_MIN = { -32 / SCALE_FACTOR, -32 / SCALE_FACTOR, -32
/ SCALE_FACTOR };
vec3_t VEC_LARGE_HULL_MAX = { 32 / SCALE_FACTOR, 32 / SCALE_FACTOR, 32 /
SCALE_FACTOR };
// In PM_Move before the call to PM_PlayerMove
for (i=0; i < pmove->numphysents; i++)
{
if (pmove->physent[i].model) // physent::model is NULL if it's not a
BSP model
{
hull_t * hulls = pmove->physents[i].model->hulls;
// Note the hulls are in different order than usual
VectorCopy(VEC_HULL_MIN, hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN, hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX, hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN, hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX, hulls[2].clip_maxs);
}
}
The other way (which is how I'm currently doing it... use at your own
risk), is to make a few assumptions (which as far as I can tell are
valid):
1. The values for clip_mins and clip_maxs are loaded once at map load time
2. The address pointed to by pmove->physent[0].model when the FIRST map
is loaded is the first element in the engine's models array and this
address does not change when a new map is loaded.
3. The order of models in the models array does not change during a map.
4. The models array has 512 elements. This one I have no way to test;
the 512 was posted previously on this list. Quake I had 256.
I added the following to pm_shared.c:
model_t * g_modelarray = NULL;
int g_model_hulls_fixed = 0;
void PM_FixModelHulls()
{
int model;
// Get pointer to the world model, which is the first element in
// the models array when the first map is loaded
if (!g_modelarray)
{
g_modelarray = pmove->physents[0].model;
}
// Special case for the world model, since its name doesn't start with '*'
// It is only the first element of the models array for the first map.
// It is always pmove->physent[0], though
hull_t * hulls = pmove->physents[0].model->hulls;
VectorCopy(VEC_HULL_MIN, hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN, hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX, hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN, hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX, hulls[2].clip_maxs);
// All the BSP models other than the world have names in the format "*%d"
// Max # of models (of all types) assumed to be 512
for (model = 0; model < 512; model++)
{
if (g_modelarray[model].name[0] == '*')
{
VectorCopy(VEC_HULL_MIN, g_modelarray[model].hulls[1].clip_mins);
VectorCopy(VEC_HULL_MAX, g_modelarray[model].hulls[1].clip_maxs);
VectorCopy(VEC_DUCK_HULL_MIN,
g_modelarray[model].hulls[3].clip_mins);
VectorCopy(VEC_DUCK_HULL_MAX,
g_modelarray[model].hulls[3].clip_maxs);
VectorCopy(VEC_LARGE_HULL_MIN,
g_modelarray[model].hulls[2].clip_mins);
VectorCopy(VEC_LARGE_HULL_MAX,
g_modelarray[model].hulls[2].clip_maxs);
}
}
}
// In PM_Move, before the call to PM_PlayerMove:
if (!g_model_hulls_fixed)
{
PM_FixModelHulls();
g_model_hulls_fixed = 1;
}
// In world.cpp:
extern "C" int g_model_hulls_fixed;
// In CWorld::Spawn:
g_model_hulls_fixed = 0; // New map - make sure all the models get
fixed again
// In hud_msg.cpp:
extern "C" int g_model_hulls_fixed;
// In CHud::MsgFunc_ResetHUD:
g_model_hulls_fixed = 0;
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SMD Exporter for max 5
You are using the wrong exporter. Look for either the one in the latest SDK, 2.3, or AlexF's exporter on maxplugins.de - Original Message - From: "Cortex" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 10:36 AM Subject: Re: [hlcoders] SMD Exporter for max 5 > Hi, > > I just ran through a bug with modeling using 3DS Max 5 and I planned to post > it there. > > To answer your question, the plugin which is distibuted with the HL SDK for > the 4.x version of 3DS Max works with 3DS Max 5 (see below). > > With all the tests my modeler (and me) ran to the same conclusion : the > geometry of the model is good exported to SMD (we haven't testes with > skeletons since we compiled only world models). Nevertheless, textures > informations are TOTALLY wrong... It looks as if the UVW mapping coordinates > were totally wrong under HLMV, whereas it looks good under 3DS Max 5... > > We've made some tests on old .max which were made with previous versions of > 3DS Max, and after opening them under 3DS Max 5 and exporting them with the > same SMDExporter plugin, it worked !! > > So, to stick together the informations, the textures informations seem to be > bad exported by the exporter under 3DS Max 5 when the model is started from > scratch. But those textures informations are well exported by the same > plugin with an old .max source file... > > So, the conclusion is, what is the difference(s) between the old and the new > .max file... We don't know. A default hidden option must have changed with > the 5th version of 3DS Max but we didn't figure out which one... > > Any help would be greatly appreciated on this... We're stuck in a very weird > bug there :( > > - Cortex : HL ALBATOR coder & mapper > - [EMAIL PROTECTED] & ICQ : 71548738 > > Phil wrote: > > Since I moved up to max 5, I've just noticed that there appears to be > > no SMD exporter for max 5. Does anybody know where I can get one? > > > > Thanks, > > Philip > > > > ___ > > To unsubscribe, edit your list preferences, or view the list > > archives, please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
where abouts did you set the values (remembering that im not much more than a dumb ass n00b) jc - Original Message - From: "Entropy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 8:40 PM Subject: Re: [hlcoders] Rescaling clipping problems (again!) > jc wrote: > > i tried the compensation thing and it didnt work that well. a > > weapon/attack that used UTIL_TraceHull suddenly f*cked up. it worked > > before the GetHull... fix, with the GetHull fix and the zhlt hack the > > players get stuck in the walls. so i've just stopped with the > > pre-GetHull fix code for now. > > If you change the clip_mins / clip_maxs, you don't need the modifications > to ZHLT, you just need a hullfile. I haven't noticed any problems with > getting stuck since changing this, so if you decide to try it I'd be > interested in hearing if you have any problems. > > Jim > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
jc wrote: > i tried the compensation thing and it didnt work that well. a > weapon/attack that used UTIL_TraceHull suddenly f*cked up. it worked > before the GetHull... fix, with the GetHull fix and the zhlt hack the > players get stuck in the walls. so i've just stopped with the > pre-GetHull fix code for now. If you change the clip_mins / clip_maxs, you don't need the modifications to ZHLT, you just need a hullfile. I haven't noticed any problems with getting stuck since changing this, so if you decide to try it I'd be interested in hearing if you have any problems. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Rescaling clipping problems (again!)
i tried the compensation thing and it didnt work that well. a weapon/attack that used UTIL_TraceHull suddenly f*cked up. it worked before the GetHull... fix, with the GetHull fix and the zhlt hack the players get stuck in the walls. so i've just stopped with the pre-GetHull fix code for now. maybe valve could resolve this issue - ie wtf is wrong with our code or a fix to engine in the next release? jc - Original Message - From: "Entropy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 6:23 PM Subject: [hlcoders] Rescaling clipping problems (again!) > I believe I have found the source of the clipping errors after rescaling. > If you look at pmove->visents[x].model->hulls for the world and BSP > models, you'll see that the clip_mins and clip_maxs for the hulls are the > original hull sizes. If that part of the engine hasn't changed from the > Quake I source, this would cause the offset returned from SV_HullForEntity > to be wrong by the difference of the player's mins - clip_mins, which is > consistent with what I had previously seen and tried to compensate for by > modifying ZHLT. (see > http://www.mail-archive.com/[EMAIL > PROTECTED]/msg04565.html > and > http://www.mail-archive.com/[EMAIL > PROTECTED]/msg04622.html) > It looks like the clip_mins and clip_maxs are set in the engine (in the > Quake I source, it's hardcoded in Mod_LoadClipnodes). At any rate, > setting BSP models' clip_mins and clip_maxs to the correct hull sizes > resulted in correct collisions. > > Jim > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] SMD Exporter for max 5
Hi, I just ran through a bug with modeling using 3DS Max 5 and I planned to post it there. To answer your question, the plugin which is distibuted with the HL SDK for the 4.x version of 3DS Max works with 3DS Max 5 (see below). With all the tests my modeler (and me) ran to the same conclusion : the geometry of the model is good exported to SMD (we haven't testes with skeletons since we compiled only world models). Nevertheless, textures informations are TOTALLY wrong... It looks as if the UVW mapping coordinates were totally wrong under HLMV, whereas it looks good under 3DS Max 5... We've made some tests on old .max which were made with previous versions of 3DS Max, and after opening them under 3DS Max 5 and exporting them with the same SMDExporter plugin, it worked !! So, to stick together the informations, the textures informations seem to be bad exported by the exporter under 3DS Max 5 when the model is started from scratch. But those textures informations are well exported by the same plugin with an old .max source file... So, the conclusion is, what is the difference(s) between the old and the new .max file... We don't know. A default hidden option must have changed with the 5th version of 3DS Max but we didn't figure out which one... Any help would be greatly appreciated on this... We're stuck in a very weird bug there :( - Cortex : HL ALBATOR coder & mapper - [EMAIL PROTECTED] & ICQ : 71548738 Phil wrote: > Since I moved up to max 5, I've just noticed that there appears to be > no SMD exporter for max 5. Does anybody know where I can get one? > > Thanks, > Philip > > ___ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Rescaling clipping problems (again!)
I believe I have found the source of the clipping errors after rescaling. If you look at pmove->visents[x].model->hulls for the world and BSP models, you'll see that the clip_mins and clip_maxs for the hulls are the original hull sizes. If that part of the engine hasn't changed from the Quake I source, this would cause the offset returned from SV_HullForEntity to be wrong by the difference of the player's mins - clip_mins, which is consistent with what I had previously seen and tried to compensate for by modifying ZHLT. (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg04565.html and http://www.mail-archive.com/[EMAIL PROTECTED]/msg04622.html) It looks like the clip_mins and clip_maxs are set in the engine (in the Quake I source, it's hardcoded in Mod_LoadClipnodes). At any rate, setting BSP models' clip_mins and clip_maxs to the correct hull sizes resulted in correct collisions. Jim ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
