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

From: Robert Bjarnason <[email-masked]>
Date: Sat, 5 Jan 2002 15:43:21 -0800

Hi,

We are currently working on a contract job
along with our game.  An educational 3D environment
demonstrating the Mayan culture.  We have created
a pyramid in a new landscape, the rbank tool
generates collision info for the landscape and
everything works fine.

Now, to be able to walk up the pyramid, boxes or
cylinders are not enough for collisions.  I've
exported collision info from 3dmax into a .cmb
file.  How do I load this file into PACS?  Can
anybody give me a hint or a code snipped?

Thanks,
Robert Bjarnason
InOrbit Entertainment, Inc.

---

From: "Benjamin Legros" <[email-masked]>
Date: Mon, 7 Jan 2002 17:05:27 +0100

Hi,

We just put the indoor collision tool in the CVS.
It should be available very soon.
You can find it in nel/tools/pacs/build_indoor_rbank.

You can build the .lr, .gr and .rbank this way :

1. Put all your .cmb files to process in the same directory
2. Check the tool config file so that the MeshPath variable points
   to it. 
3. Also put the cmb files in the Meshes list (without extension)
4. Setup output directory and output filenames

You can also choose to merge the computed indoor .lr in a previous
.gr (in order to use a single file for the whole world) by setting
Merge to 1 and the input and merge output directories and filenames
Remember the filenames shouldn't have extensions (.gr and .rbank will
automatically be added.)
Anyway, the sample config file should be clear enough (well, I hope :-)

You will find the output lr, gr and rbank in the specified OutputPath.
These files just work the same way as landscape files.
If you need more info, don't hesitate !!

Good luck !!

Benjamin Legros
Nevrax France

----- Original Message ----- 
From: "Robert Bjarnason" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, January 06, 2002 12:43 AM
Subject: [Nel] How to use CollisionMeshBuild (.cmb)

> _______________________________________________
> Nel mailing list
> [email-masked]
> /mailman/listinfo.cgi/nel
>

---

From: Robert Bjarnason <[email-masked]>
Date: Wed, 9 Jan 2002 00:56:07 -0800

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?

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?

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?

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

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 :)

Thanks,
Robert Bjarnason

---

From: "Benjamin Legros" <[email-masked]>
Date: Wed, 9 Jan 2002 12:08:11 +0100

> 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.)

> name of the instance group of the shape...I guess

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)

> coordinates based on their names for pacs to

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;
}

> not compile anymore because it can't find

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

> there, yet, only good old Gnu :)

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

Good luck !

Benjamin Legros
Nevrax France

---

From: "Benjamin Legros" <[email-masked]>
Date: Wed, 9 Jan 2002 12:11:06 +0100

Woops !!
Forgot to tell you the exterior mesh material id MUST be 666 (in MAX ids)

It seems that collisions are evil, hu ?

Benjamin Legros
Nevrax France

---

From: Robert Bjarnason <[email-masked]>
Date: Wed, 9 Jan 2002 17:30:31 -0800

Hi Benjamin,

Thanks a lot for the help :)
The exterior of the pyramid works now and I can
enter the interior through the invisible surfaces.
I haven't tried the interior collision it self,
yet.

My problem now is that when I'm at the bottom
of the stairs, on my way to the top (see attached
screenshot), then I can't walk up, pacs stops my at
the first step.  There are no actual steps yet, only
a sliding plane.  Is it maybe too steep or does the
exterior mesh collision not work for walking on top
of buildings?

Should I maybe try to make the pyramid a part of
the landscape?  Will I be able to walk into the
landscape and have an interior there?

Thanks again,
Robert

---

From: "Benjamin Legros" <[email-masked]>
Date: Wed, 9 Jan 2002 18:33:57 +0100

> Is it maybe too steep or does the

The interior collision builder doesn't take slope into
account, nor mesh geometry (as it only uses collision mesh
which is something like a curved plane), so it shouldn't
be an issue here. We, at Nevrax, also use stairs, ramps
and so on. The only issue I can see here is a vertex
misalignement between the interior mesh and the exterior
mesh, or the common edges wouldn't be invisible both.
Also check that the beginning of the stairs are not crossing
a landscape surface border (that is the 'door' to the stairs
is located inside a surface)

Last thing of all, a PACS surface must not cover itself,
for instance a spiral staircase must be divided in multiple
pieces so that for a couple of (x,y) coordinates, there is
at maximum 1 point on the surface (so a unique z).
Typically, a house that has multiple floors will be divided
by floor.

I hope this will solve your problem !

Benjamin Legros
Nevrax France

---

From: Robert Bjarnason <[email-masked]>
Date: Fri, 11 Jan 2002 15:18:44 -0800

Hi Benjamin,

I have been unsuccessful in being able to walk
up stair that are a part of the exterior mesh.
One thing I thought of before continuing my
3DMax mesh hacking, exporting and testing:

I'm using the snowballs pacs code for the client,
any chance this code might be outdated and is not
using the right VisualCollision handling for being
able to walk on top of exterior meshes?  Just checking
to make sure that my problem is not client side...
If you think it's ok, I'll continue my mesh hacking
until I find the solution, otherwise a client side
code snipped would help a lot...

Warm regards,
Robert