Hi,
I went crazy on why my app based on OSG 320 thrown away the Camera global
settings when I used osgViewer::View::addSlave.
Finally I found what seems a typo in the following enumerator (file
SceneView, row 54):
enum Options
{
NO_SCENEVIEW_LIGHT = 0x0,
HEADLIGHT = 0x1,
SKY_LIGHT = 0x2,
Hi,
I went crazy on why my app based on OSG 320 thrown away the Camera global
settings when I used osgViewer::View::addSlave.
Finally I found what seems a typo in the following enumerator (file SceneView,
row 54):
enum Options
{
NO_SCENEVIEW_LIGHT = 0x0,
HEADLIGHT = 0x1,
SKY_LIGHT = 0x2,
I've found a weird behavior in the clone() method when the sub-graph to be
cloned has a group with a ParticleSystem (or drawable) directly attached to
it.
For instance in this case if you want apply a shallow copy for drawables
and a deep copy for nodes and statesets, this piece of code will
you are looking for, but it's not a bug.
If you want to clone a subgraph and share things in a specific way then
you'll need to write a NodeVisitor to clone and share the bits you want.
Robert.
On 28 October 2014 11:14, Giuseppe Donvito giuseppe.donv...@gmail.com
wrote:
I've found a weird
I faced up these kind of linker errors when among all obj is present a
class derived from a std library class (in this case maybe osgDB::ofstream).
This seems confusing the linker (vs2013 + win7) and further requires to
always include the derived class (osgDB::ofstream) header, even if you're
What about extend the Image class, creating a storage for all faces where
the face0 is the Image base implementation?
the DDS reader will instantiate ImageCubeMap if found more than 1 face.
BR,
Giuseppe
/** ImageCubeMap class for encapsulating the storage texture cubemap image
data. */
class
gt;
> Rather than subclass from osg::Image, perhaps one could just leverage
> the face that osg::Image supports 3D images, so just store it as a
> stack of 6 images.
>
> Robert.
>
> On 11 May 2018 at 11:25, Giuseppe Donvito <giuseppe.donv...@gmail.com>
> wrote:
>
