Yes! That fixed it! Many thanks, and also thanks to Volker Settgast who privately emailed me the same solution :)
Incidently, although this identifies the problem, the solution poses an interesting question. In this particular case, I am able to artifically create a bounding box, because my "water core" artificially (as in manually) occupies a 1x1x1 cube, centered at the origin, so I am able to use -0.5, -0.5, -0.5 and 0.5, 0.5, 0.5 as its bounds. This object is then initialised as it enters the viewport server side (which unfortunately means that half way through an animation it could suddenly start initialising on servers that it has yet to appear). It also poses another slightly harder, perhaps architecturally based question. I am only able to allocate a bounding box because I "artifically" manipulate the size of the geometry, however, in the case of a piece of geometry where I don't know the size of the geometry until it is generated (and thus until when renderEnter is called), this type of server side generation would be very awkward. An example off the top of my head might be something like metaballs. As it was, initialisation didn't take place because I suspect default nodes probably have their 0,0,0 context as the "bounding object" on which nodes are culled. I guess I am thinking out loud :) Just out of interest, if I want to make the core that I am producing available to the community afterwards, how would I go about doing that? It is compiled in the same way that other librariese in /Source/Experimental are used. Many thanks, Craig Moore Research Officer University of Brighton EPOCH Dirk Reiners <[EMAIL PROTECTED]> wrote: > > Hi Craig, > > [EMAIL PROTECTED] wrote: > > > > Many thanks for your swift reply. I have been through my code and cleaned up > > the few instances without proper masking when calling beginEditCP etc. > > > > Current status, however, remains : > > Too bad. I had hoped that would have fixed it. :( > > > In all of the above cases, as I have said, if I initialise on the client I > > have no problems because the scenegraph is treated as normal. However, if I > > attempt to simply to distribute the core parameters as part of the node > core, > > and then initialise at the server side to reduce transfer of tons of > geometry, > > it is inconsistent. I am using "cout <<" statements to confirm > initialisation, > > as well as looking for the geometry on screen. One concern is that perhaps > the > > geometry is being clipped/optimised or such before it reaches renderEnter > for > > that core, is this possible? > > Actually that rings a bell. Do you set the bounding box of your derived node > correctly before you send it over the cluster? If that is not set correctly the > > node might be culled away before it's rendered. That might explain why it's > only > shown on one server, on the one that shows the origin. > > Just try setting the bbox to something big, if you don't know how big it's > going > to be, to make sure it's actually rendered everywhere. > > Hope that fixes it > > Dirk > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
