I opened an old file in H16 originally saved in H15.5. The whole model was messed up. I narrowed down the error to the polysplit nodes (see attached sample).
I'm rather new to Houdini and since i couldn't find anything on the forum my question is if this is a bug or if i'm missing something here.

Someone just submitted a bug report about what's probably this same issue. We try not to break compatibility, wherever possible, and often make a new node version if there is a major break in compatibility, but sometimes, minor changes (sometimes in completely unrelated code) may cause differences, usually unintentionally.

In some cases, compatibility must be broken once to fix a persistent compatibility issue, e.g. if you save out geometry from a SOP to a file, then load it back in, the results of operating on that geometry should ideally be the same as if the geometry came directly from upstream SOPs. One bug of that nature was fixed recently, which necessarily causes the results to be different in at least one of the two cases, since they were previously inconsistent. That change doesn't seem to be the specific cause of the change in results in this case, but we'll look into what the particular difference is in this case.

If you were modelling imperatively in Houdini 15.5 and want to continue in Houdini 16.0, the good news is that you should be able to lock the SOP at the end of the SOP chain in Houdini 15.5, and use that geometry in Houdini 16.0.

In today's build of Houdini 16.0, if you set the HOUDINI15_5_GEO_COMPATIBILITY environment variable to 1, hopefully the point and primitive order will be the same as in Houdini 15.5, (though I haven't had a chance to test this case after the change because I'm in the middle of debugging something else, so if it doesn't work, please let me know). The order changed due to fixing a bug where the order was strange in certain cases.

I have the same problem with almost all of my previous modellings. Different points and primitives order in H16. I can not use the scene files in H16. The variable “HOUDINI15_5_GEO_COMPATIBILITY” is helpful if you want to open a scene in Houdini 15.5 which has been saved using H16. The problem is opening a scene from previous versions. Any suggestions please?

vfxhomeland
Any suggestions please?

If you have a specific example, please post it. Also, you can lock nodes in the previous version to have the geometry recorded in the HIP file, so that it'll be the same when loaded in Houdini 16.

Setting HOUDINI15_5_GEO_COMPATIBILITY=1 currently (as of Houdini 16.0.530, not 16.0.504.20) undoes a point order change in Houdini 16.0, but there are likely others. You can get the latest daily build of Houdini 16.0 from: https://www.sidefx.com/download/daily-builds/ [sidefx.com]

I have version 16.0.533. However, still I have some problems. Here is a simple example and simple scene has been saved in H15.5. I can not open it correctly in H16.

vfxhomeland
I have version 16.0.533. However, still I have some problems. Here is a simple example and simple scene has been saved in H15.5. I can not open it correctly in H16.

Thanks! This was a bug in PolyBevel causing NaN values, and it should be fixed in tomorrow's build, Houdini 16.0.534, (though you'll still need the environment variable to keep the old point order in PolySplit). I'm a bit surprised that it wasn't hitting this bug in Houdini 15.5, since the bug and a bunch of similar NaN bugs that have now been fixed were there, but I guess other stuff must have changed to make it end up there in this case.

Thank you so much. I have downloaded the new build. It is very nice. It solves almost all of the problems.
Can you please also take a look at this scene which has been saved in H15.5?

I have set the HOUDINI15_5_GEO_COMPATIBILITY variable however still I have the problem. I can lock the split node and open it in H16, but this is not an effective solution.

Unfortunately, the difference between H15.5 and H16.0 in that most recent HIP file is due to some change that must have occurred before the PolyBevel feature being used was even introduced, because the difference in vertex numbers exists back even slightly before edge bevelling was introduced after the release of H15.5. The change in vertex order changes which edge the following PolySplit starts from. You can update polysplit25 after the PolyBevel to use the correct edge of primitive 432 (it's edge 8 instead of edge 1 now, so “432e8:0.461979”), or lock the last node in the modelling chain.

Despite efforts to maintain compatibility, there are going to be times when major versions change point, vertex, or primitive numbers. For example, there's a bug currently being examined whose fix will probably change point, vertex, or primitive orders for 50% of quads adjacent to or created from edges bevelled by PolyBevel, but it's a critical bug to fix, because it currently makes those orders chaotically dependent on point positions for quads that are approximately rectangular. Fixing the bug will fix the chaotic ordering, but that means that the ordering will be different from before in many cases.

Luckily, for imperative modelling based on viewport selections, it doesn't need to respond to procedural changes upstream, so locking the end of the modelling chain is what most users do. Since most imperative modelling packages just track the final geometry anyway, this is roughly equivalent, so I unfotunately don't understand why locking the end of the chain “is not an effective solution” for you if you're modelling imperatively.

To avoid any of these ordering problems, procedural modelling usually requires either using groups created based on stable conditions, (for example, a group of unshared edges), or avoiding groups altogether, (for example, using things like Boolean or volumes/VDBs to model), instead of using viewport selections that are necessarily dependent on point, vertex, or primitive orders. One possible test is that if a procedural modelling setup can withstand applying the Divide SOP's Bricker option upstream and still produce reasonable results, it's probably quite a robust setup, (though things don't usually need to be that robust for most situations).

Thank you for the information. Actually I mentioned it's not an effective way because I have to go back and lock the nodes in my scenes. However, using latest build has solved most of the issues.
H16 is a great release.

Cheers,