Could someone from sidefx please explain why the polysplit node breaks across every version of houdini? and now I recently tried working on a Mac and load my modeling files that was originally created on a windows machine and the polysplits break on the mac that's using the same version of houdini that created them on windows. The only thing customer service could tell me was that I need to cache out the model! but maybe i'm dumb cause the one of the main reason I'm using houdini is for the proceduralism and polysplit nodes are a huge part of modeling even for procedural models for me! now I have a shit load of models that can only be opened on one computer using one specific version of houdini!

This is extremely unfair and it should be documented that probably the most important modeling tool is an unstable shit show in houdini or give guidance on what the issue is and how to avoid it! If it's some memory problem, will it be solved? what is the issue?

You may want to post an example, if you want someone to try to figure out what may be the issue in your scene or whether it's really a bug

Since polysplit string is pretty clear description of what to split I'd assume it should be pretty clear if it's doing what it describes or not

Hello Tomas, here is a reduced file created on windows on H20.5; it doesn't work in H21 without polysplit errors and it doesn't work on Mac on H20.5 nor H21 for me either.

When I load this exact file on the PC it was created on in H20.5, no problems; If I try H21 on that same PC, errors all over the place! try it on mac on any houdini, errors all over the place!

from a quick look it doesn't seem like the PolySplit is the main issue

it seems like by the time it gets to Polysplit, the geo is already not containing the elements that PolySplit is supposed to split

I compared 3 different builds, but can't find a single one that would work, however all 3 resulted in different geo after "fuse2" node

it may be easier to find a culprit knowing which build has it working

hello again Tomas, it's working on 20.5.684. No errors. It's a large file with lots of models and when opened elsewhere tons of errors and all pointing to polysplit nodes.

In fact, all my files with huge modeling networks and lots of polysplits have errors in various houdini builds and only work well in the version they were created in and on the computer they were created on!

It all feels extremely fragile! I've created lots of models with semi procedural functionality where freezing does not make sense for some and I'm now very concerned!

traileverse
tons of errors and all pointing to polysplit nodes

PolySplit is very sensitive to the input geo as it needs to do split on exact prim number, exact edge, etc.
so it's likely to error out if for example is expecting to cut 10e5:0.5, but suddenly prim 10 doesn't have 6 edges anymore

so all I'm saying is that because Poly Split errors out it doesnt necessarily mean that polysplit is the issue
however if you stash the geo on node before in working build and then plug it to next PolySplit in non working and it still errors out, then you can assume it's the PolySplit, since on the same geo it should work

when I have time I'll check your file on 684 to see where the geo changes between builds

Understood Tomas, I'll try what you suggested here and do some more in depth checks to see if something else might be the issue. Thanks much!

I had a quick look at your scene (in Linux, so it errored), and of the nodes you used, these are the ones that are known to (in at least some situations) give varying results between platforms:
- smooth
- bend
- divide

Polysplit itself is consistent between platforms, but as Tomas said, the issue is that the inputs to the polysplit are changing accross platforms, probably due to one or more of the above mentioned nodes in your scene.

Hopefully if you can find the source of the difference and stash that out before switching platforms it will give you enough flexibility to make changes downstream still, if necessary. To my mind once you are specifying specific point/prim numbers in your nodes you are no longer being fully procedural, but your frustration is understandable. Unfortunately it is impossible to ensure that all nodes behave the same accross all platforms, but perhaps we can find a way of warning the user if it is known to be different. I recommend submitting an RFE requesting that, and describing the situation in which you switch platforms in more detail. Would you want to run some sort of check before switching or would you want a warning after switching, for instance?

Hello Liesbeth, as an aside, I'd be interested in a list of nodes that may output varying results depending on the platform. Does such a list exist?

I might have been a bit hasty in responding to this before. I based my previous response on looking at which nodes have different regression test results for different platforms, but much more experienced SideFX devs than me have since made it clear that that is unfortunately not a good indication of what might cause different results. Apparently even adding three floats together can give different precision results on different platforms. So while a node might behave the same with the exact same inputs on different platforms, if its function is to change topology based on input positions, even very small, imperceptable differences on the input can give different results. So it doesn't make sense to flag which nodes will cause the small imperceptable differences on different platforms, because they are ubiquitous and not picked up by our tests (because they fall below our tolerance thresholds). And you can pretty much take it for granted that any nodes that change topology based on input positions will be very sensitive to the small imperceptabe differences that are unfortunately bound to happen when changing platforms.

So when I said that Polysplit is consistent between platforms, it would have been more accurate to say that it is consistent within a certain tolerance threshold, if the inputs are exactly the same. Unfortunately if the inputs are different to within that tolerance threshold, it doesn't guarantee that the outputs will be the same.

TLDR: Ignore my previous comment. Topology altering nodes are unfortunately always going to risk being unstable when switching between platforms.

Hello, thanks much to all looking at this; I also have issues on the same platform but different versions of houdini! I did models in H20.5 that that works fine but error out in H21.

I tried stashing right before the polysplits in H20.5 and they still error out being the first node in the graph in H21 (both on windows 11 on the same computer)

I only have this issue when doing non procedural modeling which I do a lot because even for procedural modeling I might do regular poly model on a piece that gets procedurally sized and placed!

But now I just know that when using these topology tools, I can’t have too much faith in the graph history and stash/cache at checkpoints.

I have lost time redoing large parts of models that I did in previous versions of houdini that I no longer have access to and they error out in current versions and it’s always the polysplit nodes that error! and though it might be a node up the chain causing it to not work, it doesn’t do much for me because once the split entries change, everything down the chain that depended on the previous topology breaks!

But using say maya, you’d have to delete history when modeling as well; However, this was one of the coolest things about Houdini for me to have that construction history there but oh well.

Two more things.

Firstly, your model is about 2cm long, and the detail on there is incredibly fine, so it is not crazy to expect that you might run into floating point precision errors. It doesn't help for fixing this scene, but in future it might be worth scaling your model up by a value of 100-1000 when working with such small models, for instance, treating 1 unit as 1mm instead of 1m. I can't guarantee that this will prevent issues, but it might help.

Secondly, for this specific file, I managed to get it to work (I think, at least the polysplit errors went away and the result looked reasonable) on Linux in 21.0.580 by reselecting the relevant edges in "polyextrude13", "dissolve19", and "polybridge1". I figured out what the edge selections were supposed to be by opening the file in windows. Annoyingly, even though those nodes worked in windows, the polysplits didn't, so it might not be the full answer to your problem, but worth looking into and bearing in mind for future work to perhaps make a note of what edges you selected in a sticky note for polyextrude, dissolve, and polybridge nodes. Otherwise you could try stashing those nodes out, not to bake them down, but to "snapshot" your results so that you can recreate it later if necessary.

Sorry, I didn't see your last message @traileverse before I posted the above.

If your issue is with polysplit between versions with identical stashed inputs on the same machine, then that is a different matter. Something must have been changed in the node itself, or with a library used by the node. We do our best to maintain backwards compatibility, but sometimes it can't be helped. It might still be worth submitting a bug report about this problem specifically, just in case.

Liesbeth_Levick
, but in future it might be worth scaling your model up by a value of 100-1000 when working with such small models

I don't understand how this helps. My understanding of floating-point numbers is that they have fixed bit widths for fraction and exponent, respectively. If you scale the whole scene up by 1024, it'll be like adding 10 to the exponent part, but nothing changes for the fraction part.

Yes, but some nodes such as polysplit have tolerances set. The default tolerance on polysplit is 1e-5. One could of course change those values and keep working at the small scale, but given how many polysplit nodes traileverse uses, it's simpler to just model at a larger scale and leave the tolerance at default. I'm not confident that the scale is the issue here though, just a possibility.

Liesbeth_Levick
Yes, but some nodes such as polysplit have tolerances set. The default tolerance on polysplit is 1e-5. One could of course change those values and keep working at the small scale, but given how many polysplit nodes traileverse uses, it's simpler to just model at a larger scale and leave the tolerance at default. I'm not confident that the scale is the issue here though, just a possibility.

Ah, that makes sense! Thank you for the reply.

Liesbeth_Levick
I had a quick look at your scene (in Linux, so it errored), and of the nodes you used, these are the ones that are known to (in at least some situations) give varying results between platforms:
- smooth
- bend
- divide

Does this mean Houdini is incompatible with mixed-platform render farms by design? (as long as the geo isn't cached). I was about to try introdcing Linux workers to our Windows-based farm: when rendering an animation, should I expect frames rendered by Linux to potentially appear different than the ones rendered by Windows?