I have a 64-bit int attribute named foo that displays a value of 12147483648 in the geometry spreadsheet. If I then add a wrangle that does:

@foo = 12147483649;

foo becomes 1214783616 (yet foo still shows as a 64-bit int in Extended Information)

Are 64-bit attributes just not supported in vex?

VEX uses 32-bit integers:
http://www.sidefx.com/docs/houdini15.0/vex/lang#data-types [sidefx.com]

-b

Nope, no 64bit values in VEX.

As well, there is no definitive list that I know of that says which Houdini ops support 64bit and which don't.

You can recreate your wrangle expression with Python, using a Python SOP, but as you probably know already this will be a lot slower, even using a library like Numpy. However, it's the only safe way I know to ensure your values stay 64bit.

Jon

There are some hacky workarounds for particular cases.

The Attribute Create SOP evaluates numeric values as 64-bit floats, even if the attribute type is integer, and the expression library uses 64-bit floats. This means that integers from -2^53 to 2^53 can be represented exactly. With careful use of the division (/) and modulus (%) operators you can use Attribute Create to split a single 64-bit integer attribute into two 32-bit integer attributes. Be careful, because 32-bit integer attributes use signed integers, so you really only have 31 bits to work with for positive integers, and division and modulus also have strange behaviour for negative integers, (as they do in the native x86 IDIV instruction).

Then, you can use the pair of attributes in VEX, and if you want to convert any data back to a single, 64-bit attribute afterward, you can use Attribute Create for that again. Yes, it is awkward, but it often works when it's needed.

For some things, you need higher-precision floating-point numbers in VEX, and sometimes, you can use a pair of 32-bit floats to get maybe 46 bits of precision, compared with the usual 24, but it's case-dependent. For example, I used the Kahan summation [en.wikipedia.org] and other tricks in my equation solver asset on Orbolt, so that summing up data over more than 16M points won't fail catastrophically.

jparker
As well, there is no definitive list that I know of that says which Houdini ops support 64bit and which don't.

Technically, they all support 64-bit attributes in the sense that they should be able to read from them and write to them, (if they do anything with attributes), but, of course, computations using the values may or may not be done using 32-bit ints or floats, so there may be loss of precision for floats, or overflows for ints.

If there are any particular operators that you'd like to have computations done in 64-bit precision, please feel free to submit an RFE. There are already multiple RFEs for VEX to support 64-bit ints and floats. As far as I know, Transform, Object Merge, Soft Transform, and probably one or two more that I can't remember, do most computations using 64-bit floats as of either Houdini 14.0 or 15.0, if there are any 64-bit transforming attributes. Expression evaluation uses 64-bit floats. Attribute Create uses 64-bit floats. Many SOPs that just copy data won't lose precision, either, e.g. Attribute Copy. The Geometry Spreadsheet should (as of a few months ago) support 64-bit int and float attributes properly.

Cool, thanks Nick!

Well, aside from VEX… which I am guessing is on a developer or two's (or three's) todo list at SESI. And as you say it has its share of RFEs already.

I think any nodes that deal intentionally with “P” are the first that should be made 64bit safe, although I know that since I first ran up against precision issues in 9.5 there have been many improvements. The usual trick people do as a workaround is to somehow translate native positions into camera space before going to the renderer and move everything in respect to that position.

Second would be CHOPS, across the board.

I do a lot of space rendering, with camera paths that are translated from realtime space navigation apps that do a lot of clever things to solve the vast distances problem… there is really no IEEE float standard that is 100% up to the job, but I can always find a way to make things work. 64bit helps a lot though.

Thanks, folks for the info and tips.. I agree that VEX would be top of the list for supporting 64-bit attributes. At least then VEX could likely substitute for any other nodes that don't handle doing stuff to 64-bit attributes..

jparker
Cool, thanks Nick!

People seem to assume that's my first name, haha. The username “neil” was already taken, and there was some database issue, so I went with “ndickson”.

Second would be CHOPS, across the board.

I don't know for certain, but I think this is probably already the case.

In tomorrow's build of Houdini 15.0, there are several bugs fixed where the Geometry Spreadsheet was displaying or writing to attribute values as if they were 32-bit, though some cases already worked. In today's build, there was a bug fixed in Attribute Create, where if either the 64-bit integer attribute being written to was a detail attribute, or the expression depended on local variables, it was writing it as if it were a 32-bit integer attribute; (due to a silly typo on my part).

Is there any plan to fix this in upcoming 2020 y. ??

yeah.. me too was surprised that ‘designers’ should know that we can't trust floats

kodbitz
Is there any plan to fix this in upcoming 2020 y. ??

roxo
yeah.. me too was surprised that ‘designers’ should know that we can't trust floats

What smart people do here when they need to check if Point1.x is on same position with Point2.x?
I did many test using (abs(Point1.x - Point2.x) < 0.0001) and got less errors in position range of +-30 units using error threshold 0.0001 and more errors at large unit range and large range we have more threshold need to pump up to 0.01 where it just gives wrong data.
Thank you

you really need to get your best min threshold.
maybe:
0.001/100*(bbox size / numpt)

or make a grid with size you think will be max lowest in scene and use it as sample for threshold


floats not for artists