As we know, there may be several passes used in osgFX::Technique. My question
is whether different-passes-drawables would be rendered orderly as the passes
are added into Technique (pass 0 is rendered before pass 1). As I read the
source code of the file "RenderBin.cpp", I found that not std::st
Hi Chris,
As far as I know, USE_OSGPLUGIN only calls a C-styled function through a
static proxy variable, which is defined by REGISTER_OSGPLUGIN in the plugin
source code body. So compiler can thus find and register the plugin while
static linking. It should do no harm to user applications no matt
I think what Paul was asking is, if you build and install OSG, is there any
state retained anywhere (in a #define in a config.h or something) that
indicates _if_ OSG itself WAS built with OSG_STATIC, and therefore if the
application needs to configure its own #if blocks to automatically
instantiate
Hi Clay,
I don't have any object to making computeIntersections() virtual. The only
sticking point is there are a collection of different
computerIntersections() methods with different parameters, you'd need to
override all of these. What may be a better solution would be to change
the underlyi
Hi Ulrich,
On 7 March 2014 19:46, Ulrich Hertlein wrote:
> Yes, that was my understanding too.
> I was just advocating this procedure since it's sort of most-common
> practice in OSG to
> return raw pointers and the question came up.
>
Returning raw pointers is for efficiency and flexibility.
Hi Paul,
On 7 March 2014 20:50, Paul Martz wrote:
> If OSG is linked statically, obviously I need to reference a plugin with
> the USE_OSGPLUGIN macro.
>
> Is there any way I can determine at compile time whether the OSG I'm
> linking against was built as static or dynamic? I want to use USE_OS
6 matches
Mail list logo
