Am 28.06.2018 um 15:03 schrieb Robert Osfield:
> On Thu, 28 Jun 2018 at 13:57, Robert Osfield wrote:
>> The original osg::Uniform class is a bit of unwieldy mess. In
>> hindsight we shouldn't have gone for this particular implementation as
>> it's a bit too open ended.
> As a bit of background,
It would be the easiest putting an "explicit " in front of the
constructor but I guess there would be far to many reclaims then :)
- Werner -
Am 28.06.2018 um 15:03 schrieb Robert Osfield:
> On Thu, 28 Jun 2018 at 13:57, Robert Osfield wrote:
>> The original osg::Uniform class is a bit of unwiel
On Thu, 28 Jun 2018 at 13:57, Robert Osfield wrote:
> The original osg::Uniform class is a bit of unwieldy mess. In
> hindsight we shouldn't have gone for this particular implementation as
> it's a bit too open ended.
As a bit of background, Mike Weiblen with a bit of input from myself
created th
On Thu, 28 Jun 2018 at 13:06, Sebastian Messerschmidt
wrote:
> @Robert:
> Any insights?
The original osg::Uniform class is a bit of unwieldy mess. In
hindsight we shouldn't have gone for this particular implementation as
it's a bit too open ended.
In master I have written a osg::UniformBase clas
Hi Werner,
Hi all,
I recently discovered a strange case in creation of a Uniform:
farRadiusRescaleUniform=newosg::Uniform("farRadiusRescale",2.0f);
The only constructor I could find is like that:
Uniform(Typetype,conststd::string&name,intnumElements=1);
The wrong construction sometimes
Hi all,
I recently discovered a strange case in creation of a Uniform:
farRadiusRescaleUniform=newosg::Uniform("farRadiusRescale",2.0f);
The only constructor I could find is like that:
Uniform(Typetype,conststd::string&name,intnumElements=1);
The wrong construction sometimes leads to unexpecte
6 matches
Mail list logo
