Tanguy, Robert, et al:
Some good points have been raised by both sides. Singletons should be used
carefully, but are still useful in certain circumstances.
For the most part, it is a design decision - that is, it must be determined at
the highest design level whether it makes sense to allow mul
Skylark wrote:
>
> Where:
>
> HeaderStart:
>
> #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS)
> #pragma warning(push)
> #pragma warning(disable: a b c d e f g)
> #endif
>
> HeaderEnd:
>
> #if defined(_MSC_VER) %% defined(OSG_DISABLE_MSVC_WARNINGS)
> #pragma warning(pop)
> #endif
Since I want to run at /W4 without warnings, I just push all OSG include
directives back to /W2.
That is, when including any OSG headers, I surround the #include calls with
#pragma warning ( push, 2 ) and #pragma warning ( pop )
I have to do similar things with other third-party libraries I mus
J-S & Robert - with regard to C4251:
As J-S has noted, C4251 is often generated for STL usage; in particular, C4251
is often errorneously generated for STL usage in *private* members or
functions. STL usage in *public* members or functions in a DLL-exported class
is problematic (as would be pro
J-S wrote:
>
> I (and probably Robert too) thought you wanted to change the value of a
> Uniform in mid-traversal...
>
While it is true that one cannot affect the values of uniforms during a
rendering pass in the default OSG implementation, there is nothing preventing
one from changing the
Robert Osfield wrote:
> Following your logic we should also do:
>
> if (bool_variable==true)
> {
> }
>
> Rather than:
>
> if (bool_variable)
> {
> }
>
Actually, no. No ambiguity of intent is present. Only when there arises a case
where both assignment or comparison operators are logical pos
Robert Osfield wrote:
> Hi Sukender,
> Code readability is key to spotting algorithm
> errors, so any slip in readability is something to take very seriously
> which is why the !=0 is not what I would deem a good programming
> practice.
>
But I find that the '!= 0' produces far more readable c
Skylark (J-S) wrote:
>
> I'm fine with suppressing C4706 as it's true that it's a warning that
> only tells you that you *might* be doing something unsafe... Whether
> it's actually safe or not is totally context-dependent.
>
Blanket-supression of C4706 isn't really a good thing, since as yo
J-S,
/W4 is generally sufficient. I run all of my projects at warning level 4, and
effectively treat warnings as errors for my purposes. I don't enable /WX on the
off chance that I get some crazy warning that I can't suppress and isn't
meaningful in my application. I know of several such warnin
/Wall combined with any other /Wn option is redundant.
/Wall enables *ALL* warnings, including those automatically supressed by VS
under any other circumstances. /W1 through /W4 set the warning level; /Wall
goes far beyond /W4 by enabling normally disabled warnings.
I'm not sure if /Wall ignor
Just did some checking on OSG VS settings, and there are some differences in
the primary warning-supressing preprocessor options - once again, I'm not
running the current version or latest dev build, so this may have changed.
In OSG 2.6.0, the following are defined:
_SCL_SECURE_NO_WARNINGS
_CRT
/W4 on windows is far from useless, and can often point out some pretty big
mistakes that the VS compiler just happens to find a way to take care of for
you (outside of the C/C++ standard).
I haven't built a newer version of OSG - my projects here are still relegated
to running 2.6.0 for the ti
osgATK (now osgAnimation, I believe) provides an animation-based nodekit. It
should be a good starting point for looking into animation in OSG.
Your first question seems somewhat contradictory. "Vertex animation" has
traditionally referred to an older, obsolete style of animation based on saving
With regard to categorization (subforums):
It could be possible to automatically manage this from the forum side. That is,
any threads created in the forum could be tagged with an appropriate flag
designating the originating categorical subforum when they are transcribed into
mailing list messa
14 matches
Mail list logo