Two questions about bundles:

1) How does one reference a bundle in a string field? (Groups are referenced with a “@” prefix. ie: @group1). How does it work with bundles?

2) I think I understand how bundles work, and can see their usefullness in creating a light group across networks for an object's light mask string. But how else are people using bundles in everyday production?

Thanks,
Robert

Same way, with an “@”. I've been really opposed to that, since it means groups and bundles can, and do, collide. It's screwed up our pipeline enough that we can't use them much yet. Single biggest reason? We keep our Houdini lights wrapped inside OTLs - so the actual lights don't live on the /obj level. This seems to run afoul of bundles more often than not, because lights are special.

The idea of bundles are great - essentially they are groups that let you collect things that don't necessarily live in the same area, such as SOPs, ROPs, etc. They are essentially “generic groups”. Where this becomes messy is with all the filtering - it's become so complex and restricting that again, we've sort of held off on them. I'm curious, too, how some people are using them and what the big advantages are. I know some were jumping up and down about them.

Cheers,

J.C.

Using bundles more and more I found that bundles are global - bundles cannot be owned by a subnetwork/HDA - at least not without scripting them. Groups still ride with the subnetwork but don't have the capability to transcend networks. Has anyone else found the gobal nature of bundles to be fairly limiting? What is misleading as that the Bundle List Pane has an address bar which insinuates that the bundle defined might be rooted in a certain network. I'd love for bundles to have roots but if not, at least to remove the address bar.

What does everyone think about this? Am I mistaken?

Haven't had cause to use them. Groups still seem to do everything I want.
I'm also curious as to what they offer, I must be missing the point somewhere.
Come on someone out their must have a killer app for them. :wink:

Simon
I'm also curious as to what they offer, I must be missing the point somewhere.

Bundles are about the only way to handle lightmasks for subnetworked lights and other types of masks unless you list each light/obj seperatly.

I currently use groups to turn objects off and on for rendering different layers, but was thinking of switching over to using bundles since I wouldn't have to have groups in all my subnets. A bundle can contain a node that is inside a Digital Asset without having to unlock and modify the asset. An event script could be used to create or modify bundles that are needed for certain assets. We still have to unsync all the assets before changing the display flags for rendering of course but that is all handled in the render script.

I know that bundles were a bit buggy when they were first introduced. New objects would show up in every bundle so it was necessary to run a script to fix your bundles… I hope that has changed.

jason_iverson
What is misleading as that the Bundle List Pane has an address bar which insinuates that the bundle defined might be rooted in a certain network. I'd love for bundles to have roots but if not, at least to remove the address bar.

What does everyone think about this? Am I mistaken?

I'm pretty sure bundles are not rooted to any network, they are global, you can to an opbls from any network and get the same list of bundles. My first impression was that it would be confusing and defeat the purpose of them if there were multiple lists of bundles, like having different sets of global variables…. But thinking on it more it would be quite handy, a digital asset could contain it's own list of bundles, and those bundles could be bundled in other bundles…. but that's not how it works, for now at least. It would be cool if you could at least have a group in your bundle.

I'm not sure why it has the address bar, perhaps because it's a side effect of having the use of the tree view?

Drats, jrwillette beat me to this. Let's say your scene consists of lots of object HDA's which in turn have lots of geometry objects. And you want to light the geometry objects within them as opposed the entire HDA. Then I hope you start to see the picture. You really can't scale up with groups. Bundles are much better in H7.0. The issue jrwillette talks about is fixed in H7.0 (how much earlier, I forget now).

As the address bar in the bundle pane, there's an icon in the treeview toolbar called Link Selection. It's turned on by default I think. Notice that if you go to ROPs vs. OBJ the tree view changes. That's because it's looking at the address bar. Try turning it off and playing with the buttons.

Bundles are about the only way to handle lightmasks for subnetworked lights and other types of masks unless you list each light/obj seperatly.

OK, this is interesting. This is precisely why bundles *didn't* work for us. I know they were almost unusable when first introduced, and they've improved, but we keep our lights in subnets on the obj level, and groups worked perfectly well - you make the subnet part of a light group, it automatically transferred down to the light inside. We had no troubles at all.

When bundles came along, we suddenly were confronted with a system that not only collided with the groups namespace(if this had not been the case, none of this would have bugged me near as much), but tried to be “smart” about what you were trying to do with all these filtering options. What would happen is that everytime we tried to do an operation with the parent subnet, it tried resetting the filter. Other operations, which used to pass through without problems with groups, resulted in “autoexpansion” issues where you were constantly confronted with subnet paths to the real lights instead of just referring to the top layer and letting us pass through the info. In short, a major pain.

I'll be honest, I haven't examined this for a few subreleases, but a quick examination indicates things haven't been changed all that much. I need to look again in detail, though. Most confusing to me is the introduction of all these filters and the “smartness” of them. Why are they needed? Just seems to be yet another layer to manage.

Cheers,

J.C.

P.S. It's bitchy Friday - this server is as brutally slow as ever in the mornings GMT-5. Took almost 5 minutes to just get the page to enter this message. Any chance someone is considering throwing this on a cheap dedicated server that isn't used for compiling? (I assume).

Hey - did you SESI guys move already? That mean I'm not going to be constantly waving to Mark Elendt from Rassee and no more Rodney's lunches?

Sorry, John, looks like you're going to miss some fun, I see? Yeah, I think today is the big day for SESI.

Our first attempt at using bundles was a fairly complex asset with quick a few objects nested deep inside of it at various depths and we wanted to set a bundle for the reflection mask of an object to reflect them. This was when we discovered that an asset can't carry bundles as you can with groups. Well, not without scripting it - which is a bit of a drag.