Hi.

Between build 201.13 and 230 new methods for parsing groups showed, and they broke my template methods.

1. What's the fuss with all those GroupCreator arguments?

2. Can we get some more love in the “Mayor Changes in HDK” part of the documentation?

Thanks!

mantragora
they broke my template methods.

Uh oh! I was hoping they'd even maintain binary compatibility, let alone compilation compatibility, since I tried to keep all of the old function signatures identical until we split the baseline for the next dev cycle. Could you post an example of what broke? Were they the functions on GOP_Manager, or on SOP_Node that were being called?

1. What's the fuss with all those GroupCreator arguments?

Group parsing with the old functions only accepts pointers to non-const details, and even though there were options on GOP_Manager to make detached groups, it was really awkward having to cast away const, and SOP_Node didn't provide an interface to make detached groups, so in cookInputGroups, you were pretty much stuck casting away const and modifying an input detail for any group that needs to refer to the input detail, e.g. if the alone flag is set, or if it's an input that doesn't get copied to the destination. What's worse is that even if the detached flag was set, GOP_GroupParse was sometimes creating temporary groups for its own use that were not detached.

Basically, because it's relying on nobody else looking at the input detail while it's temporarily modified, this is one of the biggest remaining things preventing significant work from even starting on multi-threaded evaluation of SOP networks. I wanted to make sure that the interfaces were in place so that people have the opportunity to fix their cookInputGroups implementations in a way that will work across multiple versions, in case progress is made on that front. The old functions aren't currently marked deprecated, but they may disappear in the next major release or a following one if it ends up being urgent that they must go. I know it won't be popular when that eventually happens, because probably every cookInputGroups function uses them, and some users have a lot of HDK SOPs. I may mark them deprecated now, even though it's after the release, if people think that it makes sense. I wasn't yet sure I was going to lock down on the current interface.

Anyway, GroupCreator is (currently) defined as an inner class in GOP_GroupParse, and allows the caller to manage how groups will be created, whether detached or just internal, without the group parsing code having to know how to create groups or have a ton of separate functions for each case, (once the old ones are deleted). If you're okay with getting detached groups, you can just use GroupCreator(detail), or in some cases, even just passing the detail will automatically create a GroupCreator that will create detached groups. If you need groups that are owned by the detail, e.g. if you'll be adding/removing elements of that type from the detail, you can use GroupCreator(detail, false). I've updated the HDK examples that had a cookInputGroups function to use safe functions, but they're all parsing detached point groups for a single input, so they're not as interesting as one might hope.

2. Can we get some more love in the “Mayor Changes in HDK” part of the documentation?

Sorry. This was intended as a minor change that wouldn't affect any existing code, or even already-built binaries, for now. We didn't have any build breaks from it; just one regression test failure because I fixed a bug that the Peak SOP was relying on. It also looked like I was able to build GOP and run Houdini without rebuilding SOP, so I figured that those changes at least were binary-compatible, and I was able to build SOP without rebuilding a few SOPs that come later and that use group parsing, and their group parsing still worked, so I figured most of the changes in SOP were binary-compatible too.

I may still have to change the new interface a bit as I encounter issues while sweeping our SOPs to use it.

I tried to add all of the major changes I could remember between 13.0 and 14.0 on the Major Changes in the HDK page, but if there was anything I missed, please let me know. There were hundreds of small changes, like small function signature changes, deprecated functions being deleted, etc.

ndickson

mantragora
they broke my template methods.

Uh oh! I was hoping they'd even maintain binary compatibility, let alone compilation compatibility, since I tried to keep all of the old function signatures identical until we split the baseline for the next dev cycle. Could you post an example of what broke? Were they the functions on GOP_Manager, or on SOP_Node that were being called?

I got universal private method for parsing input groups that then I call by two virtual public methods in which I just call proper version, by specyfing do I want Point or Primitive parse. So I got switch inside that casts to proper type based on which template is called:


switch (grouptype)
{
case GA_GROUP_POINT:
{
if (success < UT_ERROR_WARNING)
{
group = GA_Mantragora_GroupTypeT(parsePointGroups(groupFieldText, detail, allownumeric, 1, false, 0));
if (!group) addError(SOP_ERR_BADGROUP, groupFieldText);

selectit ? select(*const_cast<GA_Mantragora_GroupTypeT>(group), 1) : select(GU_SPoint);
}
else select(GU_SPoint);

break;
}

case GA_GROUP_PRIMITIVE:
{
// parsing primitive
}
}


and this is error I get

e:\hdk-lib\extensions\operators\SOP/Base/SOP_Mantragora_Operator.cpp(208) : error C2666: ‘SOP_Node::parsePointGroups’ : 2 overloads have similar conversions
CPROGRA~1/SIDEEF~1/HOUDIN~1.230/toolkit/include\SOP/SOP_Node.h(537): could be ‘const GA_PointGroup *SOP_Node::parsePointGroups(const char *,GU_Detail *,int,int,bool,int)’
CPROGRA~1/SIDEEF~1/HOUDIN~1.230/toolkit/include\SOP/SOP_Node.h(531): or ‘const GA_PointGroup *SOP_Node::parsePointGroups(const char *,const SOP_Node::GroupCreator &,bool,bool,bool,GA_Index)’
while trying to match the argument list ‘(UT_String, GU_Detail *, bool, int, bool, int)’
e:\hdk-lib\extensions\operators\SOP/Base/SOP_Mantragora_Operator.cpp(1117) : see reference to function template instantiation ‘OP_ERROR Mantragora:OP:OP_Mantragora_Operator::____parse_input_groups____<const GA_PointGroup*,GA_GROUP_POINT>(OP_Context &,const PRM_Template &,GA_Mantragora_GroupTypeT &,GU_Detail *,bool,bool,fpreal)’ being compiled
with
[
GA_Mantragora_GroupTypeT=const GA_PointGroup *
]
e:\hdk-lib\extensions\operators\SOP/Base/SOP_Mantragora_Operator.cpp(222) : error C2666: ‘SOP_Node::parsePrimitiveGroups’ : 2 overloads have similar conversions
CPROGRA~1/SIDEEF~1/HOUDIN~1.230/toolkit/include\SOP/SOP_Node.h(509): could be ‘const GA_PrimitiveGroup *SOP_Node::parsePrimitiveGroups(const char *,GU_Detail *,int,int,bool,int)’
CPROGRA~1/SIDEEF~1/HOUDIN~1.230/toolkit/include\SOP/SOP_Node.h(503): or ‘const GA_PrimitiveGroup *SOP_Node::parsePrimitiveGroups(const char *,const SOP_Node::GroupCreator &,bool,bool,bool,GA_Index)’
while trying to match the argument list ‘(UT_String, GU_Detail *, bool, int, bool, int)’

The line with the cast is problematic for both cases:

//point
group = GA_Mantragora_GroupTypeT(parsePointGroups(groupFieldText, detail, allownumeric, 1, false, 0));

// prim
group = GA_Mantragora_GroupTypeT(parsePrimitiveGroups(groupFieldText, detail, allownumeric, 1, false, 0));


allownumeric is a bool in both cases

mantragora
allownumeric is a bool in both cases

Ok, now I woke up finally. Fast fix was to cast allownumeric to int
I keep to bool for passing arguments, instead of int, and old parts of HDK still use int in some places.

mantragora

mantragora
allownumeric is a bool in both cases

Ok, now I woke up finally. Fast fix was to cast allownumeric to int
I keep to bool for passing arguments, instead of int, and old parts of HDK still use int in some places.

Yeah, we're slowly trying to fix flags to be bools and functions to be const-correct. MSVC seems particularly picky about implicit casting of bool to anything else, and vice versa.

mantragora

mantragora
allownumeric is a bool in both cases

Ok, now I woke up finally. Fast fix was to cast allownumeric to int
I keep to bool for passing arguments, instead of int, and old parts of HDK still use int in some places.

Alas, it's because it treats the type conversion constructor from GU_Detail * to GroupCreator as just as significant as the type conversion from bool to int, so it doesn't know which conversion to do. Ugh. I could make the GroupCreator constructors explicit, so that it's not a valid option; that might or might not fix its perceived ambiguity.

Actually, to avoid waiting a day to guess and check, what happens if you change GOP_GroupParse.h to have “explicit” before “GroupCreator(const GEO_Detail *detail)” ?

I'm not using GroupCreator yet, so I can't test. I'm waiting for you to fix edge selections AND then I will come back to fix everything else that you broke in H14

mantragora
I'm not using GroupCreator yet, so I can't test.

The compiler thinks you might be, because without “explicit”, there's an automatic conversion from GU_Detail* to GroupCreator. Adding “explicit” should make it clear to the compiler that you're not using GroupCreator.

I'm waiting for you to fix edge selections AND then I will come back to fix everything else that you broke in H14

What's broken about edge selections?

Edge selection issues here:

http://forums.odforce.net/topic/21694-sidefx-releases-houdini-14/page-7 [forums.odforce.net]