This is a topic that has come up a few times. But I had a thought on it and figured I'd float it out and see if anything comes back.
There has always been an issue with the whole procedural modelling approach that if you change a piece of your model at the top of a network it can have disasterous results further down. This is usually due to point and primitive numbers changing and therefore selections no longer being valid.

In the past the idea of using ids that don't change has been discussed but nothing yet has come of it. So I started thinking maybe there is a much simpler way to deal with it that doesn't effect the way anything currently works. I've no idea if this would work (well I have some idea, but it's tricky to test without doing it) How about having a option that would just renumber existing selection groups based on the way the input geometry has changed?

So at any point in time if you decide that something you are about to do is going to change the point/prim count then you choose to have it's impact ripple through the whole network. So for example if you have a model with 10 prims in it and a group sop that selects prims 5-9

model
|
group prims 5-9

and then you add a delete sop in before the group sop that deletes prims 0-3

model
|
delete prims 0-3
|
group prims 5-9

rather than the group sop now being broken the renumbering process would automatically modify your group selection to be 1-4.

model
|
delete prims 0-3
|
group prims 1-4


This effect of a ripple selection update could perhaps be a toggle on each sop that would allow the auto renumbering or ignore it.

Obviously as with all solution for this problem it won't work in all cases, but would it work in enough to make it useful?
If it would work it could even be scripted. Which if I have time, ( and I don't at the moment) I'll try out and stick it up on exchange.

I'm sure it would be nice if Houdini had something like this…
but your idea just won't work….
in your eg Houdini would see that the group sop was using the last 5 prims as it's selection…then when the delete is inseted it still uses the last 5…but even with a very simple object like the one you describe using the ‘last 5 prims’ as a selection rule will break almost all the time….
it's a very tricky problem…but I think there are just too many factors involved….

I wasn't really thinking about it as “using the last five” rather that it would be using the same five. So I think it would work, like I say it's really difficult to imagine, you kinda need to do it. In my example I choose a simple situation so that it was easy to visualise. But it works in more complex scenarios, but instead of thinking of the code having to work out what the selection rule was, ie the last 5, it's much dumber than that, it just remaps base on the new value for the prim or point.
So for example in a very complex model with 1000's of polys if you delete any number of them then all the ones left get renumbered if you store the mapping that renumbers old to new you can reapply it to any list of points or prims.

eg

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ………


delete 3 4 6 10 11 12

and the mapping goes like this

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ….
0 1 2 - - 3 4 - 5 7 8 – – – 9 10 ….


0 -> 0
1 -> 1
2 -> 2
3 -> remove
4 -> 3
5 -> 4
6 -> remove
7 -> 5
8 -> 7
9 -> 8
10 -> remove
11 -> remove
12 -> remove
13 -> 9
14 -> 10
…

so if your selection is
6-10

it will be rewritten as
5-9

or if it is
0-1 3-5 7-13

it will be rewritten as
0-1 3-4 5-9


does this not work?

yep. do it.

-cpb

remapping the numbers is easy…the problem is that the resulting selections, most of the time, will not be what the user wants…there will be things missing etc….
I like the idea, don't get me wrong….I just think that it's a far more complex problem…

so is it ready yet?

one other thing that just came to mind was
checking the location of an indexed item
against uv co-ords, to see if it has
moved too far after an upstream topology
change to be a correct index re-map.
that's assuming that the uvs aren't mangled
by the changes…


-cpb

remapping the numbers is easy…the problem is that the resulting selections, most of the time, will not be what the user wants…there will be things missing etc….
I like the idea, don't get me wrong….I just think that it's a far more complex problem..

Yeah not sure, I know with the sort of stuff I would want it for it would probably work, but you're right a lot of things are more complex.

I'm thinking of situations where i need to have a small polysplit or something and then I find I want to change something in a completely different part of the model but it will still blow up the polysplit. That for me would make it worthwhile on it's own, even if it fell over in more complex situations.
It would be interesting to hear some other examples though to see if there is another way round it, I just can't believe it isn't possible somehow someway…. :roll:

so is it ready yet?

You'll have to wait a bit for this, I'm have a list of stuff to do “out of hours” at the moment, this is kinda low priority, but since i think i'll use it myself i'll get round to it at some point…. :wink:

I had a thought about this. Especialy in terms of topology changes when modeling but it would be a very good feature in other areas also. My conclusion is that more than one type of dataflow remapping is needed to handle most (if not all) situations.

Ok I am revealing top-secret stuff here, generaly reserved for Edit/GFX (codename), which is my graphics system some 12 years in stagnant development.

The reason I am posting here is Houdini paradigms most resemble my perfect system and I am so impressed with Apprentice and the Houdini community in general.

Here are mapping types, simple->complex order(system wise):

1. user assisted remapping
2. Like Simon said - downstream element renumbering/spanning
3. BSP type residency mask calculations, proximity type heuristic mapping

This could be elaborated but since this is already researched for years in mesh reconstruction and similar algorythms I wont bother.

Anyways, I would like to thank SideFx for making such a beautiful system, I started saving up my pennies but it will take a while till i get 17k*100 of them