Hi Carsten,
> well, before I burn myself again by providing misleading information
> ;),
> perhaps you could tell us a little about what you are trying to do and
> what role the type(s) you are adding have in that?
Fair enough.
All the data will be added to NodeCores and therefore added to the
scenegraph.
The current layout is:
Class type1;
Class type2 { map<string,type1> t1_map; }
NodeCore type3 { vector<type2> t2_array; }
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).
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.
> 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. I just tried a basic
implementation of type1::copyToBin/copyFromBin/getBinSize and the compiler
seems to accept it. However it will most likely take 2 weeks before I see if
it works.
Aloha, Andi
------------------------------------------------------------------------------
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
