Re: [Nel] Cluster Systems

[Loic Dachary]

        Hi,

        Here are a few contribution and questions.

s/associed/associated/
s/frustrum/frustum/

Cyril 'Hulud' Corvazier writes:
 > Let's talk about cluster systems.
 > 
 > NeL provides a complete solution for indoors clipping.
 > 
 > - Cluster System (CS)
 > ----
 > 
 > A CS is a set of clusters and portals.
 > 
 > A CS is associed with one Instance Group (IG). All the CS description is

.. associated ...

The CS description is saved into the IG.

 > saved into the IG. The CS can clip the objects referenced in its IG or 
 > "manually" inserted in the CS.

"manually" should be expanded, it is confusing. This might be better,
assuming I'm understanding correctly:

  A CS can be used to clip objects referenced in the associated IG or
 other objects, unrelated to the IG but explicitly inserted in the CS.

 > CS can be placed in a hierarchy of CS, ie, a CS can have one or more
 > children CS. The landscape is the parent of all the CS in the NeL engine. 
 > Links must be done by the NeL user with the method 
 > UInstanceGroup::linkToParentCluster ().
 > 
 > 
 > The objects referenced into the IG you want to clip with the CS must be
 > flagged as "Clusterized" with NeLExport.
 > 
 > - Clusters
 > ----
 > 
 > A clusters is a convex polytop. It can be done in 3dsmax using a mesh

A cluster is a polytop.

 > flagged as cluster with NeLExport.
 > All the objects referenced in the IG associed with the CS that intersect

associated

 > the cluster are associed with the cluster.

associated

 > At least one vertex of the mesh must be in the cluster to

of an object 

 > consider that this mesh is in the cluster. One mesh can be shared by
 > more than one cluster.

this object is associated with the cluster (or in the cluster). A given object
associated with more than one cluster.

 > When the view frustrum (VF) enter into a cluster, the object associed to

enters into a cluster, the objects associated with 

(by "enters" I guess you mean that the VF instersects with the cluster) 

 > this cluster are clipped against it, ie, they are visible if they intersect 
 > the 
 > VF. If an object associed to a CS is never intersected by the VF,
 > it won't be rendered.

        ...to a CS never intersects the VF, it won't...

 > A cluster can be flagged as "Parent Visible" with NeLExport, it means 
 > that if the VF enter into this cluster, the parent CS will be visited too 
 > by the VF.

        
 > A cluster can be flagged as "Visible From Parent" with NeLExport, 
 > it means that if the VF enter into the parent CS, the cluster will be 
 > visited too by the VF.
 > 
 > Two clusters in the same CS can be linked together using a portal.
 > 
 > - Portal
 > ----
 > 
 > A portal is a convex polygon. It can be done in 3dsmax using a mesh

... is a polytop ...
(although I'd prefer convex polygon that is less obscure to me ;-)

 > flagged as portal with NeLExport.
 > 
 > A portal MUST be placed between two clusters, ie: all the vertices 

... must be completly enclosed in the intersection of two clusters ...

 > of the portal must be in the 2 clusters. If a VF visits a cluster, for 

(is "visits" equivalent to "intersects" ? I guess what you really mean 
is "intersects after being clipped by one or more portals". Is that
right ?)

 > each portal in this cluster, the VF will be clipped against the portal, 
 > and if the VF is not empty, it will visit the second cluster linked
 > to the portal.

(I'm not sure what you mean by "clipped against the portal". Does it mean
that the clusters behind portals that do not interesect witht the VF are
ignored ?)

 > A portal must be always in 2 clusters exactly.

(redundant with the above statement, IMHO)

 > To link up in the hierarchy, you need a cluster with the flags 
 > 'Visible From Parent' and 'Parent Visible'. In such a
 > cluster you should take care of the portal(s) orientation:
 > The portal front face should look outside the CS.
 > This is the only situation the orientation of a portal is checked.

Hierarchical organization of CS depends on the properties of at least
one cluster within the CS. A cluster with both 'Visible From Parent'
and 'Parent Visible' must exists in order for a CS to be linked with
its parent in the CS hierarchy. This specific cluster must also obey
an additional constraint : the portal (1 ???) must (2 ???).

(I'm unable to translate 1) "front face" 2) "look outside". I'd really
appreciate explanations ;-)

 > A portal can be dynamic, ie, it can be opened / closed at runtime.
 > (When a door is open / close for exemple). If you want set your 
 > portal dynamic, flag it "Dynamic portal" in NelExport. At runtime, 

If you want to set the dynamic aspect of a portal, ...

 > you can get / set it using 
 > UInstanceGroup::getDynamicPortal / 
 > UInstanceGroup::setDynamicPortal.
 > 
 > - Run time
 > ----
 > 
 > At run time, the only thing to do, after loading and hierarching CS, is

.. and organizing the CS into a hierarchy, 

 > to place each movable instances into the good cluster system. 

.. the CS it belongs to.

 > NeL cluster system DOESN'T KNOW in which CS a moving object 
 > is.

There is no information related to moving objects in a CS, hence NeL
has no way to know which moving object should be placed in a given CS.

 > The reason is, we prefer using PACS collision informations that are
 > arlready performed and fasters to check than testing cluster systems.

Moving objects use the PACS collision informations for this purpose. In
addition they are pre-calculated and use less CPU than CS.

 > To do that, use an indoor collision mesh per CS. If your moving object
To place a moving object within a CS, ...

 > is over the collision mesh, then insert it into the corresponding CS. 

(is this what is meant above by "manually" ?)

 > To place a NeL instance into a CS, use 
 > UTransform::setClusterSystem ().
 > -------
 > 
 > We hope this is understandable :-)

        It surely brings a lot more light on this delicate subject. Thanks.

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
12 bd  Magenta         http://www.senga.org/      address@hidden
75010    Paris         T: 33 1 42 45 07 97          address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt