Re: Re[2]: [Nel] How to use CollisionMeshBuild (.cmb)

[Benjamin Legros]

From: "Robert Bjarnason" <address@hidden>


> Hi,
>
> I've exported a .cmb file from Max from the same
> Max file as I use to export the instance group that
> includes stairs in the Mayan pyramid we are
> reconstructing.
>
> The process explains it self and everything seems
> to work except when I load the scene no collision
> happens with the stairs.  My .rbank and .gr files
> both grow and this is the output log:
>
> 02/01/09 00:25:33 INF  708 main.cpp 234 : compute retriever 8_AO
> 02/01/09 00:25:33 INF  708 main.cpp 255 : Material 0 used
> 02/01/09 00:25:33 INF  708 local_retriever.cpp 665 : compute topologies
> 02/01/09 00:25:33 INF  708 local_retriever.cpp 709 : generated 24
topologies for character 0
> 02/01/09 00:25:33 INF  708 local_retriever.cpp 709 : generated 0
topologies for character 1
> 02/01/09 00:25:33 INF  708 local_retriever.cpp 709 : generated 0
topologies for character 2
> 02/01/09 00:25:33 INF  708 local_retriever.cpp 709 : generated 0
topologies for character 3
> 02/01/09 00:25:33 INF  708 main.cpp 195 : instance making and linking work
time: 0.010
> 02/01/09 00:25:33 INF  708 main.cpp 325 : 0.170 seconds work
> 02/01/09 00:25:33 INF  708 main.cpp 329 : CVector       translation_0 =
CVector(-2237.0f, 1149.0f, 0.0f);
>
> What I see right away that is strange it that the
> approximate middle of my stairs in the world is
> (2240.0f, -1148.0f), looks very much like
> "translation_0" except for the "-" being swapped,
> maybe this is just a coincident?

This is normal, because .lr files are centered on the
center of the computed zone (because of some vertex
compression on 2 uint16, we use local coordinates.)
So, the translation_0 is the translation used to go
from world space to local space.

There is also a really important thing for the indoor
collision export. To embed the indoor collisions with
the landscape collisions, you have to create an 'exterior
collision mesh' which will be used to collide from
landscape to indoor and to walk through doors.
This mesh must coincide with indoor/lanscape doors
(e.g. for a house, the front door) and common edges
must be invisible. In attachment, a little picture
that will probably explain more that words...

Please note that common edges must be flagged invisible
to be recognized as a door. In any case, assume that
visible edges are real wall (can't walk through) and
invisible edges are soft (can walk through).
You may divide the collision in different meshes
if you respect the visible/invisible edges (that will
allow to create different pacs surfaces, different
material, etc.)


> When I export the .cmb file then it takes on the
> name of the instance group of the shape...I guess
> that is normal, right?

Yes, and you'll get this name when you call
UGlobalRetriever::getIdentifier(const UGlobalPosition&)
Another thing is that the material id you set in MAX
for the meshes will be the id you get when you call
UGlobalRetriever::getMaterial(const UGlobalPosition&)
minus 1 (MAX ids start at 1, our material ids start at 0)


> Another thing that might be related to this not
> working is that I had problems getting the
> Landscape pacs to work until I realized the
> importance of having my zones translated to the
> correct world coordinates based on the names.
> I used the snowballs example max zones to figure
> out where they were supposed to be located.
>
> According to the Max snowballs example_zones the
> size of each zone in Max is supposed to be
> approx 4 meters by 4 meters, and that is
> supposed to translate in the NeL 160m by 160m,
> right?  I'm a little bit confused on the zone
> size issue because the units seem to be different
> in Max and NeL?  Also, am I correct to assume
> that the zones have to be in the correct world
> coordinates based on their names for pacs to
> work?

You should use MAX generic units (menu Customize,
Units setup, Generic units). Zones are approx.
160x160. Please note that PACS zones must not
be wider than 512.0 and better centered on the
grid (again for vertices compression...)

The build tool uses zone ids to translate into
local space (instead of real zone center, this
to avoid linkage issues due to float imprecision).
The linker also uses zone ids.

For your convenience, these are the functions used
in the builder to convert from float coords to name,
id to float coords, integer coords to id...

string getZoneNameByCoord(float x, float y)
{
 const float zoneDim = 160.0f;

 float xcount = x/zoneDim;
 float ycount = -y/zoneDim + 1;

 char ych[32];
 sprintf(ych,"%d_%c%c",(sint)ycount, 'A'+(sint)xcount/26,
'A'+(sint)xcount%26);
 return string(ych);
}

CVector getZoneCenterById(uint16 id)
{
 CAABBox  bbox;
 uint  x, y;
 const float zdim = 160.0f;

 x = id%256;
 y = id/256;

 return CVector(zdim*((float)x+0.5f), -zdim*((float)y+0.5f), 0.0f);
}

uint32 getIdByCoord(uint x, uint y)
{
 return y*256+x;
}


> Maybe this is unrelated but build_rbank does
> not compile anymore because it can't find
> moulinette.h

Wooops !
I just fixed it on the CVS, but you can fix it by replacing "moulinette.h"
by "build_rbank.h". Sorry...


> I include a low quality screenshot, still only
> first pass on models and textures and we don't
> have our sky-dome or visiting characters in
> there, yet, only good old Gnu :)

He he =)
The gnu reminds me of something ;)



Good luck !


Benjamin Legros
Nevrax France

coll.gif
Description: GIF image