Hi, On Wed, 2011-11-09 at 09:59 +0100, "Christoph Fünfzig" wrote: > Hi Carsten, > > On 08.11.2011 20:53, Carsten Neumann wrote: > > Hello Christoph, > > > > On 11/08/2011 03:28 AM, "Christoph Fünfzig" wrote: > >> please consider the following case: > >> I want to store a terrain as a geometry node > >> (Positions and Normals as VBOs). > >> Now I want to change small parts > >> inside the Positions and Normals arrays only.. > > > > ok. > > > >> What change policy for VBOs is actually used? > > > > Not sure what you mean? GeoProperty is handled the same way as all field > > containers. > > > I mean handling of the OpenGL API: > glBufferDataARB(GL_ARRAY_BUFFER_ARB, size1, NULL, usage); > with usage = GL_STATIC_DRAW_ARB, > GL_DYNAMIC_DRAW_ARB (VBO is only stored in HW memory), > GL_STREAM_DRAW_ARB > which are all the options. > They are not especially SG friendly as they would avoid the host copy.
in short, yes these interfaces are supported, so you can map the buffer and modify it, IIRC this should not marked the container changed so nothing will be triggered (if so it is a bug). An example can be found in: https://github.com/vossg/OSGAddOnsGV in the Compute subdir. The testSimpleCudaComputeOSG.cpp shows different ways to update VBO content. > >> With the "changed" marking of arrays, > >> would it make sense to subdivide the terrain (in a cluster)? > > > > perhaps, if sending the data over the network becomes a bottleneck. > > > >> Is it possible to change arrays without getting entries > >> into the change list? > > > > well, there is always const_cast<> ;) > > It's also probably going to break all sorts of things. More importantly, > > what would be the upside? If you are not running in a cluster you could > > make the CL read only (and anyway the CL does not consume large amounts > > of memory), if you are running in a cluster, you make your scene > > inconsistent by changing the values and not distributing them. > > > This was the intention! > Is it possible to exclude certain data, e.g. Positions and Normals arrays, > from the > change list entering and sucessive cluster sync? > Not all but certain (so no read-only CL)! > They keep their initial values and are distributed separately, just the > sketch of an idea. also possible, with OpenSG 2 you can decide per Container per Field latest at runtime whether cluster/multiaspect syncs should happen or not. I don't have a ready made example but for fields there is the following interface void markFieldsThreadLocal (const BitVector bvFieldMasks); void unmarkFieldsThreadLocal (const BitVector bvFieldMasks); void markFieldsClusterLocal (const BitVector bvFieldMasks); void unmarkFieldsClusterLocal(const BitVector bvFieldMasks); within the FieldContainer class. Container can be marked during creation by using createLocal instead of create, providing whether the container should be aspect or cluster local. For your scenario you might have to use the GeoXXXBufferProperies so the OpenGL objects are created and available ready to be filled where needed (clusterserver) without actually filling them with actual data through OpenSG. If you need more details let me know. kind regards gerrit ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
