Mapping Attributes to Capture Weights

[edward]

And it's fairly obvious from this thread that the biggest hurdle to accessing them is the fact that they're not stored as standard attributes, and so none of those wonderful attribute tools can be used with them (directly).

Oh, you have no idea how bitter I am about that. To be fair though, when all this was done, there were actually no real generic attribute tools anyhow.

Because the pCapt attribute was sparse, it was decided to store them as index value pairs. In hindsight, what should have been done was to add generic support for sparse attributes. At the lowest level, we could do some simple form of compression such as RLE. Then all the tools can just work with it as a full decompressed array of floats as needed and everything would have been hunky dory with attribute interpolation, etc. Even back 10 years ago, I think this would have been a feasible solution.

1. A simple modification of the Capture SOP:

Add a toggle to the CaptureSOP, let's call it "Attribute Override" for now. When this toggle is on, any incoming point attributes whose name matches one of the Region names, overrides its values. This behaviour is not unlike geometry attributes overriding shader parameters, for example, and I'd say is fairly intuitive, no?

This would at least give us a quick and easy "good for now" method of getting "in there" easily.

To me, a quick and easy "good for now" method is to simply make an OTL out of the chop network setup.

It would be useful to have some generic handling for manipulating arbitrary sized attributes. For index pair attributes, we can just treat the input as sparse and stuff them into the attribute in index pair form. Alas, this isn't so easy to do as it would need some new special parameter dialog UI. I'm not sure that I want bug parameter dialogs because someoned tried to create a float[100] point attribute. CHOPs is really still the best way of dealing with this.

2. Provide an alternate path that removes the need for a Capture SOP:

...

A generic solution would simply associate a controller object with a weight distribution. And whether that distribution came from using a capture sop (because you were using bones, say), or via some other yet-to-be-imagined method shouldn't matter in the least -- i.e: the "bone" thing is just a special case.

So I propose a new SOP (let's say "AttributeDeform" for now) which let's you associate a [point|prim|det]::float attribute to an object. And needless to say, the controller object would not be required to contain a CaptureRegionSOP since the weight distribution is defined by the incoming attribute. Internally this would simply build a pCapt (or add to it) structure in exactly the same way that the CaptureSOP does, ready for the DeformSOP.

The AttributeSOP would also need to be extended to handle deleting/renaming one of these "deform" attributes properly.

Did you see my posts on the HDK thread on Daniel's implementation of a wrap deformer? In H7, there's actually new internal support for such float attributes as the pCapt. Float attributes now also have a "type info" associated with them which hints at how they are to be supposed to be interpreted. If you save out a piece of geometry with the pCapt attribute to a .geo file, you will note that the type of the pCapt attribute isn't just float, but float:indexpair. This allows generic float:indexpair attributes to work seamlessly with say AttribTransfer, AttribComposite, etc. Is this want you meant by the AttributeSOP reference? I'm not sure what you meant.

There are problems with making such schemes generic. It's not enough to simply say here's a primitive/transform and its weight. For cregions, they also have shape information so that if you change the shape of a cregion at a non-capture frame, then the geometry also deforms along with it accordingly. For wires, there are actually 3 pieces of information for each primitive: weight, and the uv values closest to the primitive from the point. Then, the rest information differs as well. For bones, you need the the rest transforms of the cregion, the rest shape info, the paths to the cregions. For wires, you need to know the u ranges that the points were captured to on the primitive. At deformation time, the algorithm which makes use of this information is different. The way wires and cregions deform are fundementally different, with different deformation controls.

What you're describing above I think of as a more specialized case of the cregion deformers. In the sense that cregions offer more capabilities than just simple transforms. There would be no way to fit the wire deformers into such a scheme because you won't get a nice resolution independent method of capturing/deforming. We could relax the cregion dependencies in the Capture/Deform SOPs but then all you still get is a special case of what you could have otherwise done with cregions. Perhaps, I'm misunderstanding how you imagine a generic capture deformer scheme would work.

[edward]

The attributes are laid out in a specific manner, and the Deform and the captureSOP work with them in that manner. It kills me every day that the wireDeformer/wireCapture don't work in the same manner.

Just be glad that things didn't take a backwards step. If we only had more time ....

[sibarrick]

Hey Mario, I was looking at all this last night and thinking of tweaking my flexor stuff so that it could use the deform sop with Ed's chop network. When I started looking into it though I started thinking I'm going to need a massive amount of data stored in the capture sop. Number of points * number of bones, that is going to get pretty heavy.

How big is the data set you are dealing with and does it handle it ok?

It's going to take a fair bit of tweaking to get my stuff to work and I don't want to try it if in the end it's slower than what I have already.

[Mario Marengo]

Hey Edward,

Thanks so much for the detailed response.

Because the pCapt attribute was sparse, it was decided to store them as index value pairs. In hindsight, what should have been done was to add generic support for sparse attributes.

I'm certainly not qualified to make any meaningful comment on that, but I do understand what you're saying. And I'm sure that in any project as big as Houdini there are bound to be multiple opportunities for regretting some early design choices. But please understand that all I was suggesting was opening a tiny back door to allow us to manipulate capture attributes with the same flexibility that we currently enjoy when working with plain attributes; not an overhaul of the entire deformation system (I had a suspicion that those roots might run deep... plus I don't think it's needed for what I'm asking).

To me, a quick and easy "good for now" method is to simply make an OTL out of the chop network setup. smile.gif

Hehe... I thought you might say something like that

OK. Fair enough. But before I comment on the OTL, I'm going to have to force your hand with regard to part 1 of my suggestion, since you didn't actually make a direct comment on it. So, do you think it is: Simply redundant given that your chop solution could be turned into an OTL? Unnecessary? Hard to implement? Or what exactly?

With regard to the chop solution... for some reason my weights started to get scrambled after about 12 regions or so (my system needs to deal with 32 regions in total). Now; it's entirely possible that I screwed something up when I copied/adapted the nodes (a manual copy since your original was done in Apprentice). I wanted to investigate some more, but I've spent waaay too much time on this part of things already, so I'll have to leave it until after the job is done (for now I've reverted back to the old method) .

I also noticed the hardcoded pCapt[0-3] entry in the Geometry chop that grabs the CaptureSOP's regions. I obviously modified this to suit my needs, but this would have to be made smarter if the system is to be useful -- perhaps there's a way to infer the num of regions in the source, or turn it into a couple of params and let the user specify the range directly... pCapt[`ch("../start")*2-1`-`ch("../end")*2-1`]... would that even parse?... didn't have time to look into this either...

It would be useful to have some generic handling for manipulating arbitrary sized attributes. For index pair attributes, we can just treat the input as sparse and stuff them into the attribute in index pair form. Alas, this isn't so easy to do as it would need some new special parameter dialog UI. I'm not sure that I want bug parameter dialogs because someoned tried to create a float[100] point attribute. CHOPs is really still the best way of dealing with this.

Yes, I see how that could turn into endless headaches.

Though you're thinking in much broader terms than I was. In this case I think it suffices to think of the array length as simply the number of points in the incoming geometry (or only those with non zero valued attribute entries if you want to bring sparseness into it), its member values the attribute values, and the "glue" that I was after as an operation that maps between this geometric representation and your pCapt structure -- a light-weight operator that maps between the (already existing) storage structures (geometry-based attributes and pCapt) without (hopefully) the need for additional low-level support. But yes, I'm only talking about the weight distribution part of the data.

Did you see my posts on the HDK thread on Daniel's implementation of a wrap deformer?

I saw it but haven't had the chance to read it carefully yet, sorry.

This allows generic float:indexpair attributes to work seamlessly with say AttribTransfer, AttribComposite, etc. Is this want you meant by the AttributeSOP reference? I'm not sure what you meant.

All I meant was that if we were to think of those capture weights as normal (non indexpair) attributes, then there perhaps should be a way to delete/rename them as well... an afterthought, no more; and very much secondary to the main idea.

There are problems with making such schemes generic. It's not enough to simply say here's a primitive/transform and its weight. For cregions, they also have shape information so that if you change the shape of a cregion at a non-capture frame, then the geometry also deforms along with it accordingly <more interesting stuff, but snipped for brevity>.

Yes, but am I wrong in thinking that these are just various examples of ways in which to define weight distributions? The shapes are allowed to change dynamically (and depending on the chosen method, the underlying shape could be a curve, a "pill", or whatever), and a change in the shape's parameters/transforms results in a change in the distribution. My procedural weights are also allowed to change dynamically (multiple override files), but even though these changes are brought about by a different set of rules and relationships, the end result is the same: a change in the weight distribution. And whether the change is dynamic or not is inconsequential to the basic mechanism, which is: "some action" results in "some weight distribution". And I'm suggesting to add procedural methods (stored in plain attributes) to the set of possible actions.

The second part is how the chosen method interprets these weights for the purposes of carrying out the actual deformation. And naturally each method goes about it in its own particular way, requiring different state data to support it (though they will all need the weights at a bare minimum). But I don't think any of this changes the fundamental problem raised in this thread, which is: there's no built-in way to define deformation weights procedurally. Notice we're talking about the weights, and not the mechanism that carries out the deformation (to the same extent that the CaptureLayerPaint SOP manipulates only the weights, for example).

What you're describing above I think of as a more specialized case of the cregion deformers. In the sense that cregions offer more capabilities than just simple transforms. There would be no way to fit the wire deformers into such a scheme because you won't get a nice resolution independent method of capturing/deforming.

How so? In my particular case I base the weight values on, among other things, texture uv's, parametric uv's, curvature, bounding box.... none of which are resolution dependent. And I could probably think of a whole bunch of other resolution-independent ways. Actually, for all we know, resolution dependence is *exactly* what the user needs for a specific task. The whole point of a procedural weight is that the method in which it is defined is arbitrary, and more importantly, unknowable by the application developper. That was the extent of my use of the word "generic".

Let's see if I can condense what I'm after here...

SESI (or you yourself for all I know ;-) has seen fit to add the necessary tools to allow us to "paint" weights. And users everywhere rejoice! It is a very useful tool indeed, as it allows us to define arbitrarily-shaped regions, thereby freeing us from the tyrany of predefined shapes (curve, pill, sphere), which, while *very* useful in their own right, are not the answer for all occasions since they're essentially built with a specific application in mind. (no single dedicated method could fit all requirements all of the time).

There's only one problem: paint regions are static (in time and constant in value).

So, the point of my rambling? It would be at least equally as useful (and in some cases downright necessary) to be able to define these weights procedurally. And since we have a very good set of tools for manipulating attributes, it seemed natural to suggest that all we'd need in order to achieve procedural weighing would be a means to map point attributes directly to capture regions. Unfortunately, in this scheme, the word "capture" is inappropriate since the attribute values themselves embody the result of the procedural equivalent of "capturing" (ie: how they received their values is immaterial since it was done in some arbitrary way by the user). This last is what prompted me to suggest dispensing with the need for a capture sop (in this particular case) and providing a new sop whose job would simply be to stuff these attributes into a form that is ready for the DeformSOP's consumption -- the pCapt structure.

This hypothetical SOP would take a second input for the rest/reference shape if that was needed by the deformer, and similarly for any other data required by the deformation system, whether dynamic or invariant.

If you think there's *any* way in which to add this kind of functionality (and ignore my suggestions since they are obviously uninformed with respect to how they may impact the implementation side), then this whole thread can be viewed as an effort to try to convince you that it is perhaps worth doing. And given the responses so far, I'd even venture that it might be a *very* well received enhancement to boot!

Cheers, and thanks for taking the time to explain things in such nice detail Edward. Much appreciated!

[Mario Marengo]

Hey simon,

Hey Mario, I was looking at all this last night and thinking of tweaking my flexor stuff so that it could use the deform sop with Ed's chop network. When I started looking into it though I started thinking I'm going to need a massive amount of data stored in the capture sop. Number of points * number of bones, that is going to get pretty heavy.

16918[/snapback]

My stuff is pretty light -- 32 regions/controllers, so it performs really well. But I've never had to push it beyond that so I have no idea how well it scales.

But as I mentioned in my previous post, I came across some problems (which I could have inadvertently introduced myself), but haven't got the time right now to look into... maybe you can confirm whether it continues to work properly with something heavier than my little example in this thread.

Cheers!

[sibarrick]

If you think there's *any* way in which to add this kind of functionality (and ignore my suggestions since they are obviously uninformed with respect to how they may impact the implementation side), then this whole thread can be viewed as an effort to try to convince you that it is perhaps worth doing. And given the responses so far, I'd even venture that it might be a *very* well received enhancement to boot!

Cheers, and thanks for taking the time to explain things in such nice detail Edward. Much appreciated!

16922[/snapback]

Very well recieved

And ditto on the time spent explaining things.

[edward]

Ok, this reply is not going to be so detailed because I already wrote a detailed one which got lost.

To me, a quick and easy "good for now" method is to simply make an OTL out of the chop network setup. smile.gif

...

So, do you think it is: Simply redundant given that your chop solution could be turned into an OTL? Unnecessary? Hard to implement? Or what exactly?

If the CHOP solution works, then the first suggestion is unnecessary.

With regard to the chop solution... for some reason my weights started to get scrambled after about 12 regions or so (my system needs to deal with 32 regions in total). Now; it's entirely possible that I screwed something up when I copied/adapted the nodes (a manual copy since your original was done in Apprentice).

I think that we might need to also sort the tracks. It was probably easy not to notice because we only had 2 regions which got swapped. BTW, you could have used opscript.

to be useful -- perhaps there's a way to infer the num of regions in the source, or turn it into a couple of params and let the user specify the range directly...  pCapt[`ch("../start")*2-1`-`ch("../end")*2-1`]... would that even parse?... didn't have time to look into this either...

I had already logged an RFE to have some expression to determine the size of an attribute. As for your expression, I don't see anything wrong with it.

the "glue" that I was after as an operation that maps between this geometric representation and your pCapt structure -- a light-weight operator that maps between the (already existing) storage structures (geometry-based attributes and pCapt) without (hopefully) the need for additional low-level support. But yes, I'm only talking about the weight distribution part of the data.

Can't CHOPs do this?

All I meant was that if we were to think of those capture weights as normal (non indexpair) attributes, then there perhaps should be a way to delete/rename them as well... an afterthought, no more; and very much secondary to the main idea.

That's not necessary as delete/rename attribute operations are generic.

My procedural weights are also allowed to change dynamically (multiple override files), but even though these changes are brought about by a different set of rules and relationships, the end result is the same: a change in the weight distribution.

So are you saying that it's perfectly ok to stick to the standard transform blending equation that the Deform SOP uses because you're going to change the weights to work within that framework?

Sure, in that case, I think that the WireDeform SOP is flexible enough to do that. With it, you don't need any objects to do the weighting at all. Which is what I was suggesting to Daniel in the other thread. The WireDeform in the next major release of Houdini will support point normals on deformer so you won't have to worry about rotations.

So, the point of my rambling? It would be at least equally as useful (and in some cases downright necessary) to be able to define these weights procedurally.

Can't CHOPs do this?

[Mario Marengo]

"CHOPs can do this".

Got it.

[Mario Marengo]

OK. Friday was a very long day and I was in a crappy mood by the time I read your post. Apologies.

But Edward, I could replace every instance of "Can't CHOPs do this?" in your post with "Can't TCL/TK do this?" and be just as rhetorically "correct". After all, the tcl solution was used on about 300 shots in production. But I started this thread hoping to find a clean, integrated way to do this among all the new tools that have been added since... and was a little dismayed to find that there was (still) no built-in way to do this.

Going through CHOPs is a much much better method than using tcl, and I will adopt it as soon as I have the time to fix some of the kinks mentioned, and package it into an OTL. So you see, I'm not arguing its merits as a solution. I like it. It's good.

But here's where our opinions seem to diverge:

After looking at the CHOP solution I thought to myself: "this is really neat but it still seems awkward... wouldn't it be great if this stuff was seamlessly integrated with plain attributes (and the rest of the package)?... to the point that their differences in storage become transparent to the user?... wouldn't that be nice?... hmmm?". At which point I (probably mistakenly) offered up some ideas for a possible interface, where "part 1" was the simple attribute-to-capture-weight mapper (yes; the direct analog to your CHOP chain, but built into the CaptureSOP). And "part 2" was my attempt at something a little more sophisticated, something maybe as flexible as AttributeCreate, but which could deal with capture weights.... <sigh>... I probably shouldn't have made these suggestions as they took the conversation into the realm of implementation, where none of us users can make convincing arguments since we can only base our opinions on what we infer from the interface and a mountain of conjecture.

And yes, CHOPs can do many things. They could, for example, be used to replace most (all?) of the functionality in the CaptureLayerPaint SOP (a combo of the Paint SOP and your CHOP chain). And yet, I'm glad that it wasn't implemented that way. Anyway... I think there's room for discussion on whether there should be some unification of plain attributes and deformation-related attributes/weights. I also believe that such a unification would be a great boon to users and the package in general -- something that seems to be echoed by some users in this thread. That's all.

Our opinions seem to differ in that you seem to be offering up the CHOP solution as final (all that's needed), whereas I see the need for this solution to even exist, as a symptom of something larger that could use some looking into.

But I'll drop all that now since I don't want to drag it out forever. And again, apologies for that curt post -- you just caught me at a bad time.

Now back to the more tangible topic of the CHOP solution:

I just remembered now (not in front of Houdini at the moment) that I also had to insert the region names in the Rename CHOP... it just hit me now, but this is most likely what caused the scrambling of the regions... this could be a problem. The normal attributes don't have a built-in order (except maybe creation order?), but the indices into pCapt (after capture) *do* have an implicit order (whatever the Capture SOP chose as the insertion order)... and at the point of renaming, the name order must match the pCapt order... am I on crack or could this be a problem?

Did you come up against this problem Simon? (I'm not using Houdini at the moment, so maybe I'm imagining things).

Cheers!

[edward]

OK. Friday was a very long day and I was in a crappy mood by the time I read your post. Apologies.

None taken. It sounds like both you and I need a vacation.

and was a little dismayed to find that there was (still) no built-in way to do this.

I think our views differ here because when I see CHOPs as "built-in" as much as anything else.

it just hit me now, but this is most likely what caused the scrambling of the regions... this could be a problem. The normal attributes don't have a built-in order (except maybe creation order?), but the indices into pCapt (after capture) *do* have an implicit order (whatever the Capture SOP chose as the insertion order)... and at the point of renaming, the name order must match the pCapt order... am I on crack or could this be a problem?

The indices are into the string index pCaptPath detail attribute. I think it's in the traversal order. To confirm what the ordering is, you can write out the geometry to a .geo file and manually inspect this. This brings up an issue which I discuss below.

After looking at the CHOP solution I thought to myself: "this is really neat but it still seems awkward... wouldn't it be great if this stuff was seamlessly integrated with plain attributes (and the rest of the package)?... to the point that their differences in storage become transparent to the user?... wouldn't that be nice?... hmmm?".

In my mind, the one true solution to the indexpair attribute problem is to NOT have indexpair attributes in the first place. ie. remove them altogether one day and do the compression stuff I mentioned earlier. Of course, whether that day will come is an entirely different matter. That's my main (but perhaps ill-thought) reluctance to deal with adding tools to deal with them.

Ok, so let's see if I understand correctly what your RFE is in concrete terms. A SOP which combines a series of float[1] attributes into one arbitrary sized attribute with an optional toggle to say whether the destination should be an indexpair attribute. For the indexpair attribute generation, the ordering will be a problem though. If we base the ordering based on a some look up attribute (ie. pCaptPath), then we run into the problem that cregion names have spaces which would eliminate matching attribute names since they can't have spaces. So one would need three extra parameters to deal with this. Two parameters to specify the string index attribute to do the lookup and its class (point/prim/detail). Another one to do a mapping from attrib name to lookup value. All the extra index pair attribute handling is just plain ugly but feel free to submit an RFE.

If we ignore the ordering problem and you're willing to just "figure" that out (say, confirmed by looking at the .geo output), then an HDA can be done today. Although I think the cregions are ordered based on the traversal.

My other thought was that if you're going to be define these 1D arrays procedurally, then the best way to do it is in CHOPs. I would simply create the entire pCapt tracks in CHOPs using whatever expressions, references, etc. and then bring it in using a Channel SOP. So in your example setup, I wouldn't have used those AttribCreate SOPs at all. No need to even bring in the existing pCapt attribute. Just recreate it all in CHOPs.

Finally, if we want to get rid of cregions, then the framework to use is the wireCapt attribute. Then you just need to munge attributes on geometry without any need of extra objects. So the tools to do this are the same.

[sibarrick]

Did you come up against this problem Simon? (I'm not using Houdini at the moment, so maybe I'm imagining things).

Cheers!

16962[/snapback]

I didn't get a chance to try it out yet. Once I realised that I would need

npoints * ncapture regions * 2 entries of data I was slightly put off. I will try it out when I get a mo but I'm less excited about it than I was at first.

I suspect that some way of dealing with sparse attributes is needed for efficency.

Ed, what are your views on this, does having huge amounts of extra effectively unused entries cause massive efficiency problems in the deform sop? I can't see how it wouldn't.

Does the wirecapture sop suffer from this at all?

And one final question, is the deform sop quicker than the wiredeform sop? I'm thinking the deform sop probably does less work?

In the skin example I did with my flexor system the base skin model has 14,363 points in it and at least 150 cregions that 4,308,900 attributes, I just can't see it handling this.

As I say I will still try this because I have other much simpler models that would probably work very nicely with this approach.

Of course with the updates to the wirecapture sop in the pipeline I might be able to just use that anyway without any need to munge any capture data.

[Mario Marengo]

Hey Edward,

None taken. It sounds like both you and I need a vacation.

Yesssss! I'm starting to day-dream of Costa Rica... hmmmm....

Well... this week is a disaster, but I should resurface around friday. I'll be able to check out your suggestions then I hope. (I'm a little puzzled about how all the pCapt attributes relate to each other... gotta have a closer look at that... but I can't now).

Until then... Thanks.

[Mario Marengo]

I didn't get a chance to try it out yet. Once I realised that I would need

npoints * ncapture regions * 2 entries of data I was slightly put off. I will try it out when I get a mo but I'm less excited about it than I was at first.

I suspect that some way of dealing with sparse attributes is needed for efficency.

16977[/snapback]

Riiiight. Forgot about that issue. Hmmm. Maybe there's a need for the HDK surfacing here?

Crap! gotta get back to work... later.

[thekenny]

I wasn't kidding when I said the attributes are laid out in a "very specific manner". I don't think there is a nice way to mix and match attributes unless you do as Ed describes and do it all in chops (yikes! I don't believe I've done that before... send someone to CHOPs on purpose).

There is some logic to it, but just from experience using the capturePaint and captureEdit and multiple caputreSOPs in a large character capturing

network in the efforts to organize how the captures play well together it was difficult to keep it all straight and nice. Which is why, I guess, the

captureLayer idea came about with the attributeComposite. Although the captureComposite has other uses, it is the best way to handle the merging of standard capture weights. Since Mario is defining his procedurally, it just gets more arbitary to the point where it would be easier to not use the standard tools at all but use CHOPs. Scary isn't it.

Really when you get down to it the decisions and style for the attributes are really legacy, almost as old as the limbSOP if it was still there. Sure it has some new features, but they are more glue than anything. If you go down the route of using arbitrary attributes to base your deformations by, almost all SOPs would need the ability to deform those attributes as well, much like the current deform handles 'N'. I mentioned this idea back with Simon's wireCapture/wireDeformer thread as well. You could actually do a lot more with that information.

As far as speed, I think the deformSOP is pretty fast when you think what it is doing. As long as the attributes are not changing above the deform all of that information is stored once, then assumed to be the same. (if you toggle on assume co-ordinate changes) When you look at how Houdini actually handles internal information and memory consumption they have traded off a lot of 'same as' information structure from op to op so they always know how to treat the data. Opscript out all the objects and look at how every object has basically all the same parameters. It is set up so they can pass the information around quickly and know where to get it from fast. Sure it takes up more memory but the standards gives them the accessibility we all love so much.

-k

[edward]

does having huge amounts of extra effectively unused entries cause massive efficiency problems in the deform sop? I can't see how it wouldn't.

Does the wirecapture sop suffer from this at all?

And one final question, is the deform sop quicker than the wiredeform sop? I'm thinking the deform sop probably does less work?

16977[/snapback]

I think it's gonna have to slow down for sure for any extra zero weighted primtive that it has to process. The wiredeform sop is the same thing but the nice thing about it is that you capture to the wire directly without needing to worry about the resolution of the curve.

As for the speed differences between the deform and wiredeform sops, I think the deform sop will be faster given the same number of primitives. However, the wires will effectively allow you to use less cregions for the flexors? I don't remember offhand right now whether you resampled the curves in order to create all your references frames.

Now that we actually have attributes which are tagged as indexpairs, it might be a good idea to get the Channel SOP to have a toggle(?) that will condense into the sparse form when the destination is an indexpair pair attribute.

[sibarrick]

Now that we actually have attributes which are tagged as indexpairs, it might be a good idea to get the Channel SOP to have a toggle(?) that will condense into the sparse form when the destination is an indexpair pair attribute.

17000[/snapback]

Now that might be the quick answer! That way we could stick with using the chop solution but have some efficiency too.

I wonder if it would just be possible in chops to filter out all the zero pairs? That must be doable.

Another thought is that I could maybe break the problem down into regions and then use the attributecomposite to merge them all together..... maybe

This definately warrants some time spent on it. There must be a nice solution in all this somewhere. At least for the short term

Of course I'm forgetting the problem of the traversal order, that's the real kicker in a big setup. How to neatly order the attributes in the same order as the capture sop??? hmmmm that still needs a clever idea. I can only think of saving out the capture file and then parsing it, and then doing something with that. But that's real messy.... don't like it. Need a way to sort prims by making attribute names to objects names, but in the same order that the capture sop traverses hierachies....... phew that might take a serious hack.

Edited March 22, 2005 by sibarrick

[sibarrick]

I gotta say having looked at this some more and re-read the thread again i still get stuck on ordering the attributes.

I also can't help thinking that one of Mario's earliest suggestions was perhaps the best.

1. A simple modification of the Capture SOP:

Add a toggle to the CaptureSOP, let's call it "Attribute Override" for now. When this toggle is on, any incoming point attributes whose name matches one of the Region names, overrides its values. This behaviour is not unlike geometry attributes overriding shader parameters, for example, and I'd say is fairly intuitive, no?

This would at least give us a quick and easy "good for now" method of getting "in there" easily.

And Edwards reply

To me, a quick and easy "good for now" method is to simply make an OTL out of the chop network setup. smile.gif

I think the answer to this is now that the chop network isn't really the answer because it has the draw back of not being able to sort the attribute pairs in the same way as the capture sop.

Still like the idea of an "Attribute Overide" would this be possible?

To the layman it doesn't sound so hard, in essence were saying replace the need for an external override file with an internal one.

Still looking at the option of the wirecapture and wiredeform combo. But until we have the update on that with the rotations fixed it hard to say if it will work even if the attributes can be hacked.