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. >> 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.
Thanks, your comments were very helpful, Christoph -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ------------------------------------------------------------------------------ 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
