Hi Robert,
Abstract: I don't necessarily agree, but I do see your point. The reason
I don't agree, is that OSG is pretty much documented by its code. So in
such a case, I would expect the code to auto enforce these rules. If
not, then I would otherwise expect having that information in the
do
Hi Jean-Oliver,
On Thu, Dec 24, 2009 at 2:04 PM, Jean-Olivier Racine
wrote:
> Thanks for the quick reply. It is, indeed a node. But if the node was not
> intended to be used as-is, shouldn't it be abstract?
Sometimes in C++ you have to be pragmatic about this stuff as forcing
it be abstract caus
Hello Robert,
Thanks for the quick reply. It is, indeed a node. But if the node was
not intended to be used as-is, shouldn't it be abstract? Yet, it seems
that it is not treated like that at all within the code. In fact, the
visitors' apply(osg::Node&) method suggests that you can actually end
Hi Jean-Olivier,
Could you try outputting the data to a .osg and have a look at the results.
It sounds like somehow an osg::Node has got into the scene graph, and
osg::Node is really just meant as a base class from Node's so not
something you'd put in the scene graph.
Robert.
On Wed, Dec 23, 20
Hello all,
I think I just came across a bug in 2.9.6, revision 10691. I save a tree
(very simple one) which has been created from importing a tree using the
3ds plugin (log below):
-- LOG BEGINS --
INFO: OSG: Opened DynamicLibrary osgPlugins-2.9.6/osgdb_3dsd.dll
INFO: OSG: texture->name=OAK1.
5 matches
Mail list logo