"Renumber CPs" ?

[robcat2075]

During Live Answer Time today, >Renumber CPs came up.

 

We found it does change some CP numbers, but for what purpose?

 

Who asked for it and can you explain its intention some?

[detbear]

RC....Looks like nobody will respond. Maybe Steffen created it to help on one of his projects.

[Rodney]

I have a vague memory that the reordering had something to do with export to OBJ format.

Something related to trying to resolve the issues leading up to five point patches and hooks but... slightly before that.

I'd suggest looking into topics frequented by Malo and Nemyax related to that subject.

[Rodney]

This is the only topic I could find that appeared related to the subject (guys named Detbear and Robcat... and other animals) contemplating the renaming of CPs.:

 

https://www.hash.com/forums/index.php?showtopic=44008&hl=renumber&do=findComment&comment=378740

[nemyax]

I'd suggest looking into topics frequented by Malo and Nemyax related to that subject.

I can't think of a practical use for CP reindexing. Maybe Malo can.

[Rodney]

I can't think of a practical use for CP reindexing. Maybe Malo can.

 

One purpose suggests itself to me but it's not for direct use but for reference.

 

We found it does change some CP numbers, but for what purpose?

 

What I would imagine it could be used for is a comparison of one model to another.

For instance, if a model is saved and then altered and saved again with a new file name those two models can then be compared and the change isolated via a difference check.

Further, several comparisons could be ran to extract more useful information.

For example: the comparison could be made both before and after the renumbering of CPs to firstly isolate the area that needs to be inspected (all other areas can then be set aside as trivial unless needed again). The renumbering process is executed and another comparison ran which identifies the CP order of change. Now we have the area of interest and the identity of CPs that remain unchanged and those that have changed. We can flag those that are unchanged as clean and those changed as dirty (or vice versa if the output direction of dataflow needs to change). Clean can be manipulated further without refinement while those dirty must be processed further with respect to the ideal topology (which may or may not be the original model that was saved). Then it's mostly a matter of assigning CPs to their most likely equivalent in another space (i.e. yet another topology or change)

 

More practically speaking, renumbering of CPs seems to be a step one might take just prior to saving a (master) model that one wants to use as the exemplar; a model that is considered final and

will never change. This is the equivalent of a read only file one that should be referenced but never altered. This exemplar is the model that is production ready and any change (in topology) from it will prove costly because that change will break something further down the food chain. As a best case scenario the change will just go along for the ride (and might not impact anything) but it sits in a hotspot waiting clandestinely for the opportunity to break things.

 

This whole workflow would be of interesting usage in combination with versioning as iterative states of the same file could walk up and down the historical record showing the states of change (and even inbetweening them as necessary to create a form of resolution-independent view of prior states). This would be the ultimate undo because all changes could be dialed back to a former state. And moreso... the data can be used to project and identify potential/future states. A near equivalent of 'living data' that can aid the animator by maintaining/repairing and 'animating' itself.

[nemyax]

More practically speaking, renumbering of CPs seems to be a step one might take just prior to saving a (master) model that one wants to use as the exemplar; a model that is considered final and will never change.

If all you want is to create a master model, any CP order is as good as any other. There's no reason to renumber them for that.

[Rodney]

If all you want is to create a master model, any CP order is as good as any other. There's no reason to renumber them for that.

 

I'll have to disagree with that but I don't know your reasons for forming that opinion.

Let's assume we are in agreement but just looking at the same thing from different vantage points.

 

The principle of primacy could be used to argue a 'first saved best reinstated'.

But that would run up against the principle of recency where 'the most recent is more easily recalled' because it's what we have immediately at hand.

In this scenario the master gets lost and is replaced by the new which may or may not be 'better' in the present light or situation..

 

At any rate, I can't subscribe to the underlying idea that any CP order is as good as another with perhaps one exception.

That case might be in a perfect state where CPs are equal.

In other words, it's the change (potential or realized) that makes the reference useful or necessary.

To counter the idea from a different angle consider that the idea of ' one is just as good as another' would suggest no need for optimization. All orders being equal suggests nothing can be improved upon either.

We all know this isn't the case. But optimization itself is variable (some orders being more appropriate than others) because what is optimal (well ordered) in one case will not be so in another case.

 

The master model by itself doesn't provide anything particularly useful outside the closed system. It's when matched up against other models whose make up is different that we have opportunity for useful contrast and comparison.

 

If the CP order of a (master) file is in a optimized state then it might be ideal but if not it may not have full title to that of mastery as of yet.

In this we might have to consider from where we are taking our measurements that define mastery.

I will assume that in A:M each CP is named and numbered in chronology. If CP number 17 is deleted, the next CP created is 17 but the next available number after the current count of CPs. (I've never checked so may be wrong here!). I must therefore assume that a heavily edited model has CP numbers all over the chart with respect to order and placement. A reordering of CP numbers then optimizes them based on some specific criteria (which I can only guess at). I must assume it's not from top to bottom of mesh. Nor is it from right to left. Although... importantly... once ordered, these numbers can be recalculated that way if necessary. This ordering can then be used to determine and project other efficiency. Without yet looking, I *think* the order (of renumbering CPs) is according to spline assignment and continuity. That would make sense to me. And this would be my exhibit A against the idea that 'any CP order is as good as another' in that I would think that CPs are best ordered when they align with spline assignment and continuity.

[nemyax]

And this would be my exhibit A against the idea that 'any CP order is as good as another' in that I would think that CPs are best ordered when they align with spline assignment and continuity.

 

We'd have to look at the spline walking code to determine if that is the case. But it's very unlikely that the order matters for efficiency. A pointer to a CP object is just that, regardless of the CP object's index attribute.

 

The "Renumber CPs" operation eliminates the gaps in CP numbering, so that if your object doesn't have CP #4 but its highest is #65536, then the operation assigns a contiguous range where you do have #4 but don't have #65536 any more. That's all the optimization you get out of it.

But anyway, you'd never exceed the 4 billion upper limit for the CP numbers, so the renumbering operation is probably purely for cosmetic effect.

[Rodney]

the renumbering operation is probably purely for cosmetic effect.

 

That may be the case and even if so can be quite useful. Someone looking at a screen (or text file) might logically relate CPs #45 and #47 together but might not consider CPs #45 and #65536 as related.

Again, we'd have to look at what the code of the Renumber plugin actually produces. Easy enough to test.

 

Interestingly, we appear to be speaking of a class of users that actually care about CPs assignments; which would appear to be programmers.

It follows that Steffen might have produced such a thing primarily as a programming aid.

The majority of users very likely don't care.

 

A:M has a long history of shielding users from the arcane code that passes behind the scenes.

For someone that just wants to dive in model and animate that's a good thing.

[detbear]

The case in question for me is that if I import an obj model into Hash(not as a prop but via the obj import)from say........MAX or Maya.....I get an obvious CP number for each cp.

 

The difficulty comes when I go back into Maya/Max/etc. and move a limb(like an arm) and then export the same model again into A:M. Nothing has changed at all but the slight movement of the

arm, etc.

 

Yet the two imported models have completely different cp numbers. So you can't copy cp position data of the movement because the cps are different. And there's no way that I can think of to revert the numbering system to

match.

[nemyax]

when I go back into Maya/Max/etc. and move a limb(like an arm) and then export the same model again into A:M. Nothing has changed at all but the slight movement of the arm, etc.

Yet the two imported models have completely different cp numbers.

Why does that happen? Does the A:M importer assign CPs differently every time? And how does the renumber command help?

Have you tried importing the same OBJ twice and comparing the CP numbers?

[detbear]

Hey Nemax,

 

Not sure why that happens. Could be the exporter or the importer in Hash.

 

Yep....I did compare and if there's any changes in the position of any cp's, it has a completely different numbering on import.

[Malo]

Hello,

I don't know why this option is in AM.

However I have seen:

- Model exported is lighter! (This is an important option for storage)

- There are not unused numbers for Cp's name. (The format is cleaner).

- The organization of CPs in the splines is better.

- Rendering patches is slightly different (very small hurt) (but I think it's just a coincidence)

That's basically what I could see.