Hi Nicholas, My name is Bosheng and I am a developer from Softimage.
Thank you for your statement here and your mention is true, but I think we designed these comparison logic purposely. We just defined our CRef ">" and "<" that way. I guess what you would like to do is twisting the predicate in your sort function a bit to: using "==" to check whether the two operands are the same object before invoking ">" or "<". Sorry for the inconvenience. Thanks and Regards, Bosheng. From: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Burtnyk Sent: Saturday, May 05, 2012 7:31 AM To: [email protected] Subject: Re: Why is Material::operator& private? Well I'm glad this list exists! It's great for bouncing ideas around and the fact that the Soft devs are actually active here is fantastic! I hope I can start to contribute more and be helpful to others. On Fri, May 4, 2012 at 3:59 PM, Raffaele Fragapane <[email protected]<mailto:[email protected]>> wrote: I don't know who you are Nicolas, but I'm suddenly glad we have you around on the list and using Soft :) On May 5, 2012 2:21 AM, "Nicolas Burtnyk" <[email protected]<mailto:[email protected]>> wrote: Unfortunately, that doesn't work. CRef::operator< performs a lexicographical comparison using CRef::GetAsText(). In my scene when I have the same material assigned to multiple objects, the CRefs I get back from X3DObject::GetMaterials() give me different results from GetAsText even though they compare equal (and they are indeed the same material). Example: A bunch of objects with "Scene_Material" assigned, and 1 object (torus) with "Material" assigned. This is the result of calling GetAsText on all the materials I get from calling GetMaterials on all the meshes in the scene. //all materials (unsorted) Model1.sphere.Scene_Material Model.cube.Scene_Material Model.cylinder.Scene_Material Model_Instance.torus.Material cone.Scene_Material Material disc.Scene_Material Material These materials are in a std::vector<CRef> called "materials". I then want to remove duplicates, so I call: std::sort( materials.begin(), materials.end(), CRef_Pred::less() ); materials.erase( std::unique( materials.begin(), materials.end(), CRef_Pred::equal() ), materials.end() ); where the predicates here evaluate to CRef::operator< and CRef::operator==, respectively. In case you're not familiar with the stl algorithms, std::unique removes duplicates from a sorted range by moving them to the end of the container and returning the new end of the range with no duplicates. The important thing is that the range must be sorted for the algorithm to work correctly. Turns out that the lexicographical comparison is not appropriate for CRef sorting since 2 CRefs can be both equal and less than at the same time! CRef m1, m2; m1.Set(L"cone.Scene_Material Material") m2.Set(L"disc.Scene_Material Material") m1 == m2; //true! m1 < m2; //true! assert( (m1 == m2) != (m1 < m2) ); // <--- Wrong assumption! So, as a result, calling std::sort on my vector of CRefs doesn't correctly sort the vector: //all materials (sorted) Model.cube.Scene_Material Model.cylinder.Scene_Material Model1.sphere.Scene_Material Model_Instance.torus.Material <-- Oops! cone.Scene_Material disc.Scene_Material And therefore my removal of duplicates doesn't work correctly: //all materials (unique) Model.cube.Scene_Material <-- ! Model_Instance.torus.Material cone.Scene_Material <-- ! So CRef::operator< is not suitable for sorting. On a side note, that means it's also not really suitable for use in a map (the 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 <[email protected]<mailto:[email protected]>> wrote: Do you really need to instantiate ProjectItem objects ? Try using CRef::operator < in your predicate instead. -mab ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Steven Caron [[email protected]<mailto:[email protected]>] Sent: Thursday, May 03, 2012 8:46 PM To: [email protected]<mailto:[email protected]> 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 Burtnyk <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: the on-the-fly construction of 2 ProjectItems to do the comparison is a lot slower than if I had those ProjectItems (or Materials or whatever) already. Slow is a relative term so let me be more specific - on my machine, constructing 100 Materials from 100 CRefs and calling GetObjectID takes about 0.16ms whereas simply calling GetObjectID on 100 Materials take only about 0.001ms. Probably not a big deal :)
<<attachment: winmail.dat>>
