Re: [Hgengine-devs] Finding Nodes

[Charles L. <ch...@cn...>]

1) We do sometimes need direct interaction (or at least could heavily
use it).  I.e. We have a gameplay screen, you have several actors moving
around on a map, your scene graph has many translation nodes, and inside
them actors.  The gameplay screen (or some gameplay node that parents
those nodes) would want to obtain a handle to those translation nodes in
order to move the various objects around.  I believe it would be
possible to guarantee that the direction of these operations would be
parent-to-child only, thus the updates could thread across unrelated
nodes, and across all siblings.

2) Indeed not all objects need be named!  Naming would be optional, and
would be useful only when you need to find things.  I feel it might be
useful to be able to index _any_ named node, because I could forsee a
point where someone using the engine just gets pissed off because it is
broken in that regard.

3) My suggestion for having an every object register is solely to make
runtime-reloading of objects possible. It could simply be some sort of
global data structure with all of the nodes, indexable by pointer, i.e.
set<...>.

Charles

Josh wrote:
> Not all nodes need to have a name.
> I don't like having to pass a string into object constructors, like we 
> did in HG1.  Should this register be used only for things that want to 
> be found by other objects?  What is the intention here?  Direct 
> interaction between nodes should be minimized to help us thread updates 
> in the future.
>
> Josh
>
>
> Charles Lohr wrote:
>   
>> Devs,
>>
>> I'm looking into adding a way for nodes to be indexable globally and
>> locally.
>>
>> In HG1, we were able to say OBJECTREGISTER.GetObjectByName(
>> "MyCameraControl" );  And it would return a pointer to the object
>> "MyCameraControl." Also, we were able to, if need be, get a list of all
>> of the objects.
>>
>> In HG2, I feel like it would be useful to be able to have the same
>> functionality there.  Maybe, all objects could be indexed by name.
>>
>> Also, HG2 could have an additional feature (This is actually what I want
>> first):  Another function, to say GetChildByName( "NameOfObject" ); That
>> could search a current node's children and its children's children for
>> that node.  This function could/should be asymptotically slower than the
>> overall object register.
>>
>> This would leave us to implement two things:
>>
>> 1) OBJECTREGISTER (using an std::map<> or an MHash)
>> 2) GetChildByName function added to MercuryNode.
>>
>> I could implement both.
>>
>> My only concern with #1 is it does add to the overhead of objects if
>> they have to register with some central command, so-to-speak.  We could
>> avoid this by making it so only named objects register with
>> OBJECTREGISTER.  This does remove the feature of being able to get a
>> list of all objects, but I am not really sure what the right tradeoff
>> here is...
>>
>> Charles Lohr
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Hgengine-devs mailing list
>> Hge...@li...
>> https://lists.sourceforge.net/lists/listinfo/hgengine-devs
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Hgengine-devs mailing list
> Hge...@li...
> https://lists.sourceforge.net/lists/listinfo/hgengine-devs
>