Hey guys,
I'm wondering if anyone here knows why Material's operator& is private.
This is preventing me from doing something like this:
struct Material_less
{
bool operator() (const Material& lhs, const Material& rhs) const
{
return lhs.GetObjectID() < rhs.GetObjectID();
}
}
void SortMyMaterial
8:10 AM
To: softimage@listproc.autodesk.com
Subject: Why is Material::operator& private?
Hey guys,
I'm wondering if anyone here knows why Material's operator& is private.
This is preventing me from doing something like this:
struct Material_less
{
bool operator() (const M
timage-boun...@listproc.autodesk.com
[softimage-boun...@listproc.autodesk.com] on behalf of Chris Chia
Sent: Thursday, May 03, 2012 5:16 AM
To: softimage@listproc.autodesk.com
Subject: RE: Why is Material::operator& private?
Hi Nicolas,
If I were you, I will have a super class which extends the Material so that
lf of Chris Chia
> Sent: Thursday, May 03, 2012 5:16 AM
> To: softimage@listproc.autodesk.com
> Subject: RE: Why is Material::operator& private?
>
> Hi Nicolas,
> If I were you, I will have a super class which extends the Material so
> that I will always maintain the integrity of Material i
in a rendering context speed is paramount, keep up the good fight! and the
pressure on the autodesk to make the improvements you need.
On Thu, May 3, 2012 at 5:41 PM, Nicolas Burtnyk wrote:
>
> the on-the-fly construction of 2 ProjectItems to do the comparison is a
> lot slower than if I had tho
ent: Thursday, May 03, 2012 8:46 PM
To: softimage@listproc.autodesk.com
Subject: Re: Why is Material::operator& private?
in a rendering context speed is paramount, keep up the good fight! and the
pressure on the autodesk to make the improvements you need.
On Thu, May 3, 2012 at 5:41 PM, Nicolas
ehalf of Steven Caron [
> car...@gmail.com]
> Sent: Thursday, May 03, 2012 8:46 PM
> To: softimage@listproc.autodesk.com
> Subject: Re: Why is Material::operator& private?
>
> in a rendering context speed is paramount, keep up the good fight! and the
> pressure on the autodesk
ojectItem objects ? Try using
>> CRef::operator < in your predicate instead.
>>
>> -mab
>>
>> From: softimage-boun...@listproc.autodesk.com [
>> softimage-boun...@listproc.autodesk.com] on behalf of Steven Caron [
>> car...@gmai
he line in the docs
>> "This is useful for sorting operations with stl maps." is not correct.).
>>
>> -Nicolas
>>
>>
>> On Fri, May 4, 2012 at 4:27 AM, Marc-Andre Belzile <
>> marc-andre.belz...@autodesk.com> wrote:
>>
>>> Do you
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Saturday, May 05, 2012 7:31 AM
To: softimage@listproc.autodesk.com
Subject: Re: Why is Material::operator& private?
Well I'm glad this list exists! It's great for bouncing ideas around and the
fact
are the
> same object before invoking ">" or "<".
>
> Sorry for the inconvenience.
>
> Thanks and Regards,
>
> Bosheng.
>
>
> From: softimage-boun...@listproc.autodesk.com [mailto:
> softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas
Material.
-mab
From: softimage-boun...@listproc.autodesk.com
[mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Nicolas Burtnyk
Sent: Tuesday, May 08, 2012 1:05 PM
To: softimage@listproc.autodesk.com
Subject: Re: Why is Material::operator& private?
Hi Bosheng,
Thanks for your
: softimage@listproc.autodesk.com
Subject: RE: Why is Material::operator& private?
The CRef < operator does not behave correctly with assigned materials and
wouldneed to be fixed. The lexicographic comparison is ok for regular objects
but not for assigned materials which is a special cas
13 matches
Mail list logo