Inter Quake Model (IQM) real time collision

[toneddu2000]

Hy guys, I'd need to spawn an architectural entity in FTEQW (an arc with pylons for example) in realtime through quakeC. So I basically do this:

void spawnmyarc(vector wheretoplace)
{
precache_model("models/test/arcwithpylons.iqm");
setmodel(self,"models/test/arcwithpylons.iqm");
setorigin(self,wheretoplace);
}

If I omit the setsize function, engine, obviously, doesn't display the model at all infact setsize description is:

Code: Select all

Sets the e's mins and maxs fields. Also relinks collision state, which sets absmin and absmax too. */

This is good for convex meshes like a box or a rock, but if you place an arc with pylons and then set setsize using the maximum area covered by the mesh it will be impossible to pass through it!

I found a pretty cool method, thanks to gb and Spike, to use collision shader to map misc_models. My question is, could it be applicable to dynamic loaded meshes like iqm models?

My (ideal) pipeline would be:
1) Model in blender an arc with pylons with a material name arc
2) Model a raw collision mesh that wraps arc models made of cubes and apply collision material to it
3) Load the arc in realtime through quakec

Is it feasible? Would it need some "maquillage" at the engine code?
Thanks guys I'm stranded!

[Spike]

'surfaceparm meshcollide' is parsed by q3map2 rather than fte. this makes it valid only in q3bsp, but does mean that it can work on dedicated servers (where shaders are not parsed).
as a general rule, fte avoids loading anything but bsp objects on dedicated servers. this makes it awkward to use an iqm for collisions.
an animated iqm/model will animate through whatever its meant to be blocking.
in theory you can use SOLID_BSP and utilise whatever logic MOVE_HITMODEL uses, even without that flag set. at the current time, I believe its limited to point collisions. just don't expect movetype_push to actually push (it'll likely move straight through half the time and get blocked the rest, typically with the blocker *inside* it). hopefully the server will realise that it needs to load the model this way (you should set sv_gameplayfix_setmodelrealbox if you want servers to actually load on precache).
if all else fails, you can always spawn mulitple bbox entities.

[toneddu2000]

Thanks Spike for your reply

'surfaceparm meshcollide' is parsed by q3map2 rather than fte. this makes it valid only in q3bsp, but does mean that it can work on dedicated servers (where shaders are not parsed).

I see, so, basically, right now could it be impossible to use the method of collision meshes ingame because server doesn't parse shaders at all, right?

as a general rule, fte avoids loading anything but bsp objects on dedicated servers. this makes it awkward to use an iqm for collisions.

Adding this feature to fteqw, would it be a completely ovewrhaul? Or would it be feasible?

in theory you can use SOLID_BSP and utilise whatever logic MOVE_HITMODEL uses, even without that flag set. at the current time, I believe its limited to point collisions. just don't expect movetype_push to actually push (it'll likely move straight through half the time and get blocked the rest, typically with the blocker *inside* it). hopefully the server will realise that it needs to load the model this way.

I must admit, I don't know nothing about MOVE_* stuff. Can I use them outside traceline(for example for physics collision detection)? What do you mean by "point collisions"? I don't need that collision meshes move, they just lie in. Imagine a level made by visual meshes and their correlative collision ones.
I was thinking... can i spawn a map? For example, I create a map 512x512x512 with misc_models and collision meshes trick and I compiled it. Now, can I spawn the bsp INSIDE another bsp like an entity? No, uh?

(you should set sv_gameplayfix_setmodelrealbox if you want servers to actually load on precache)

Load what? IQM models? But, doesn't it load them anyway?

if all else fails, you can always spawn mulitple bbox entities.

No, that's the only one not feasible. Imagine a ground floor like this:


as far as I know, you can't rotate bboxes so you can't reproduce that uneven ground but just a flat ground, no matter how ground blocks are uneven one from each other

Thanks again Spike

[Spike]

you likely wouldn't want such uneven ground in an fps anyway, at least for player collisions.

if you can figure out q3map2, there might be a way to compile a misc_model as an inline/sub model. I've never personally tried.

I said it was a general rule, not a strict one. the server can supposedly load+use mdls/etc for 1) setmodel setting the 'correct' model size. 2) MOVE_HITMODEL hitting mesh geometry instead of just bbox. 3) SOLID_BSP entities.
SOLID_BSP on non-bsp entities is basically untested. It should work as well as MOVE_HITMODEL, but I'm not gonna claim its any more robust than that (the point collisions thing means it probably isn't really usable).

point collisions, as opposed to boxes. points are tiny points. ie traceline vs tracebox.

[toneddu2000]

you likely wouldn't want such uneven ground in an fps anyway, at least for player collisions.

Why? Too much computation per-frame or for a gameplay reason(possibility to block / strand between boxes)?

if you can figure out q3map2, there might be a way to compile a misc_model as an inline/sub model. I've never personally tried.

My question was different. Spawn() function can spawn bsp inside another bsp map?

I said it was a general rule, not a strict one. the server can supposedly load+use mdls/etc for 1) setmodel setting the 'correct' model size. 2) MOVE_HITMODEL hitting mesh geometry instead of just bbox. 3) SOLID_BSP entities.
SOLID_BSP on non-bsp entities is basically untested. It should work as well as MOVE_HITMODEL, but I'm not gonna claim its any more robust than that (the point collisions thing means it probably isn't really usable).

So, setting sv_gameplayfix_setmodelrealbox, server will load models, right?

point collisions, as opposed to boxes. points are tiny points. ie traceline vs tracebox.

Ok thanks

[Spike]

Why? Too much computation per-frame or for a gameplay reason(possibility to block / strand between boxes)?

player physics gets all juddery as you pass over each pebble. its not nice. plus all the jutty out parts will block movement. you need some very good movement code to be able to handle that sort of thing gracefully. most will panic under the conclusion that they've hit an fpu precision issue and are now hitting the same surface over and over again.

My question was different. Spawn() function can spawn bsp inside another bsp map?

it can, yes - think of quake's ammo boxes.
I don't believe FTE supports multiple q3bsps (or q2) loaded at a time though, just q1. this is something I keep meaning to fix, but I never find the motivation.

So, setting sv_gameplayfix_setmodelrealbox, server will load models, right?

The cvar is technically not needed as they should get loaded on demand anyway. The cvar just makes sure they're loaded by precache_model instead of inducing a stall when they're actually touched.

[toneddu2000]

Thanks a lot Spike, now it's more clear. I'll make some tests with BSP and I'll post it here

[toneddu2000]

ok, done. Thanks A LOT Spike! Your advice really helped me! So, again, a little tutorial is a must!

Environment models at runtime with nice collisions

1) Model your object, in this case an arc, in your favourite app - I used Blender but any 3d app that support natively or via plugin WaveFront's OBJ export should work
I saved it in models/test/arc.obj
Note: In Blender, it's better, to use FTEQW's orientation, to model the object using side view as front view and front view as side view so your front is game front

2) Export the object like image - remember orientation

3)create in common.shader the transparent entry (it will be used as collision hull)

Code: Select all

textures/common/transparent
{
   surfaceparm nodraw2
   surfaceparm nolightmap
   {
      map textures/common/transparent.tga
      alphaFunc GE128
      depthWrite
      rgbGen vertex
   }
}

For transparent.tga just create a 32x32 (or whatever) black image with a black alpha channel and exported as 32 bit .tga

my arc model has this shader (this is just an example, for the misc_model you can, of course use the shader you want)

Code: Select all

textures/test/arc
{
   nomipmaps
   {
      map $nearest:textures/test/arc.tga
      rgbGen entity
      alphaGen entity
   }
}


4)In Radiant (I chose NetRadiant because GTKRadiant seems to have problem importing OBJ models) create a misc_model and choose models/test/arc.obj (or whatever / wherever you saved your obj )

5)Now surround your arc misc_model with thin boxes with transparent shader applied to it. I used 1-unit wide boxes because we only need their collision

6) Compile. I used q3map2 with only -bsp pass, without nor -vis neither -light

<build name="q3map 32bit with collisions only BSP">
<command>[q3map2] -custinfoparms -meta -v &quot;[MapFile]&quot;</command>
</build>

With my version of q3map2 it yells a "MAP LEAKED" warning but it compiles fine anyway. Don't know if yours will compile too. Let me know if it doesn't.
7) add in quakeC just add this constant string and this function:

Code: Select all

string   MAPMODEL1 = "maps/miscmodel2.bsp";
void SpawnArcBSP(entity e,vector where)
{
   e = spawn();
   e.classname="scene_mesh";
   e.solid = SOLID_BSP;
   precache_model(MAPMODEL1);
   setmodel(e,MAPMODEL1);
   setsize (e, [-8, -8 ,-8], [8, 8, 8]);//fake size just to display the model, otherwise collisions are present but no model is displayed!
   setorigin(e,where);
}


A shot in game

Now you can use that function in worldspawn() function to spawn that at level loading or using it via other code or via impulse or whatever

I didn't test it too much tonight so I don't know how constant creation / deletion of BSP models can affect framerate / stability but I'll make more experiments and I'll let you know
Done! Now you can have complex environment models at runtime with good collisions!
Thanks again Spike!!