Re: Merging of CEL AI branch in CEL trunk

On Thu, 2012-08-23 at 11:01 +0100, Sam Devlin wrote:
> I agree, whilst there are minor differences between the two (one sets
> two markers the other sets an agent to walk between the two) it does
> seem redundant to have both. Especially as appsteering also has an
> example of an agent moving along a path generated by a navmesh. I
> think appnavmeshtest should be kept for generating navmeshes and
> testing the construction of paths, for this a marker at both ends
> would suffice and arguably be clearer than having an agent moving
> around. Furthermore appnavmeshtest does not (if I remember correctly)
> use the deprecated behaviours/behaviour layer that apppathfindingtest
> does.

Another idea would be to finalize the iPreProcess interface (see
http://crystalspace3d.org/trac/CS/wiki/Tools%20plugins), then put the
generation tool of the navmesh as a pre-process, and use it from either
a (generic) command line tool and/or the cseditor/AresEd.

In all cases, appsteering can probably be removed as you mention it.

>           Using key-value pairs (kvp) in maps (<key>) might be a way,
>         in addition to config file settings.
>           That led me to wonder whether io_scene_cs support KVPs yet,
>         nor map nodes,
>           but it doesn't seem so. How would that be added ?

I'm not aware of any dedicated Blender widgets that can be used easily
for KVPs. Ideas someone?

> I agree strongly here, I didn't notice this until I tried to generate
> a navmesh for the life sim demo. Making the combined tool more
> generalisable by making which map is loaded and these parameters
> something that can be set outside of the code (i.e. without
> re-compiling) would make the apps significantly more useful.

As a side note, it is also to be noted that an application may have to
maintain several navmeshes for a single scene: if the application is
using several entities of different sizes, it may wish to define one
navmesh per size of entity.

> Whole sectors can be excluded by not adding them to the HNavStruct,
> but I presume you mean smaller areas? Also could you clarify what you
> are referring to as far as "even if they'd be walkable
>   by agents settings rules ?"

I guess that with "even if they'd be walkable by agents settings rules",
Vincent meant that he is willing to define some areas that would be
excluded from the navmesh, even if the agent settings for the navmesh
computation would select them as walkable and include them in the
navmesh.

Maybe this can be made by defining an additional set of 'masking'
meshes, to be defined in the configuration file of the navmesh
generation process.

The masking meshes would be added and used when generating the navmeshes
and would therefore remove the access to some parts of the scene.

It is also possible to first generate the navmesh, then go in cseditor
and select some parts to be removed. But this most probably less clean
since you would need to redo the work every time you change the level.

>         - is there "area" supports, in addition do discrete 3D
>         positions for target/arrival destination ?

AFAIK this is not supported by R&D. And the idea of Sam can be used to
define a single circular area, but you cannot a priori combine several
areas and check for the closest one.

Managing efficiently this problem may need to be done directly at the
R&D level. We may have to go, check and ask on their forum for that.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/