Hello Andreas,
Andreas Halm wrote:
> The current layout is:
> Class type1;
> Class type2 { map<string,type1> t1_map; }
> NodeCore type3 { vector<type2> t2_array; }
thanks, that is very helpful.
> All this data needs to be available at all servers in the cluster, as
> rendering is impossible without it. Type1 contains 5 floats as I already
> said (to be exact, it is one Vec3f and two additional floats), it is
> actually a set of possible locations together with their likelihood. Type2
> contains a lot of additional data, 4 strings, 2 floats, one char plus the
> "pointer to cached data" discussed in another thread. The map contains said
> locations plus a description for them (no idea how to do a map in OpenSG,
> but as far as I can see currently I'm not using that functionality anyway).
maps are a possible, but need a bit of work since we don't have an
AField (AssociativeField) type to represent them directly.
One way to do them is to use two MFields (one for keys, one for values)
and keep the keys sorted so that you can use a binary search to locate
the key.
Another way is to put a std::map as value in an SField. Since in your
case you are not storing pointers this would not be too much work. You'd
need to give the appropriate copy{To,From}Bin functions and access would
require to always use getValue() to get a reference to the map:
typedef std::map<std::string, Type1> T1Map;
Type1 t1;
Type2RefPtr t2;
t2->editSFT1Map()->getValue().insert(T1Map::value_type("here", t1));
If you need pointers as the value (especially pointer to FC) it becomes
more involved, as now the ref counting has to be managed as well.
AttachmentContainer does this (we store attachments in a
std::map<UInt32, Attachment *>).
> Type3 contains an array of Type2, usually contains about 20 or so items. A
> lot of other data also.
> I guess you might have an idea now where all my questions come from ... this
> is a setting that is covered nowhere in the examples ;-)
>
> One fact that could be used is that once the scene is built, it is not
> changed, so there is no need for any fast insertion or deletion into t1_map
> or t2_array.
> You might think that this somehow looks like a subgraph, and actually you
> are correct. It wouldn't be wise to use Nodes and NodeCores for that though,
> as the node count would then increase from like 250 to 100.000.
agreed, for this type of thing it makes sense to compress the subgraph
into a few/single NodeCore by using special types of cores.
>> In general, for something that has value semantics putting it in a
>> field
>> is probably the right approach (it preserves the value semantics and
>> these types are normally small enough to not be a problem when copied
>> around). When you need to store and synchronize pointers the pointed to
>> object should be FC so that OpenSG has a chance to transport the
>> pointed
>> to object over the network.
>
> That is an extremely helpful comment, I somehow keep forgetting that.
> I keep thinking that type1 as explained above is small enough to implement
> in a struct, and type2 should be FC-derived.
yes, that sounds like a good approach.
> I just tried a basic
> implementation of type1::copyToBin/copyFromBin/getBinSize
did you implement these as member functions of type1 ? I suspect that
won't work if type1 is not a FieldContainer. For FC the serialization is
implemented as member functions (usually in the auto generated Base
type). For data stored in Fields a non-intrusive approach is used so
that types that can not be modified can still be used as data. The
serialization for those is implemented in a traits class: FieldTraits<T>.
Cheers,
Carsten
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
