Upon opening up a file everything seems fine, but upon closer inspection some of the objects have absurd values.
They also disappear upon moving and/or show weird behavior upon updating.
All can be seen on pictures below.
How to fix this?
I am having the same issue. Didnt pick up on the values but geometry is disappearing when trying to edit them. A forum member suggested updating all the model. It caused some things to disappear but what was left is editable for now.
I have also sent a model to visualArq.
@Sven_Duplić @Martin_Johnson we have fixed this error in VisualARQ 2.13. But we still don’t know why this happened. If you can shed any light on that, it would be very helpful. For example, what did you do right before you noticed that change. Or how were those slabs created?
Thanks for the reply and glad to hear you fixed it - can I download the fix somehow (I really need it because I have everything modeled in visualarq…)?
No idea when or how it occurs… Sometimes it all occured when opening up a file. Sometimes it seemed to pop up ‘spontaneously’ while I was modeling other stuff. And remember - it’s not only on slabs - I’ve noticed walls, columns and beams do this as well… Btw, slabs were created from a polyline.
Maybe it has to do something with the ‘runaway decimal points’ (meaning: when Rhino calculates volume, sometimes that volume has infinite amount of numbers after the decimal point…)?
Maybe it has to do something with the fact that I have layers of zero thickness in both my wall and slab? But I’ve noticed walls and slabs that don’t have zero thickness layers disappear as well…
@Sven_Duplić thanks for these details. Actually, we haven’t fixed this at all. What we have fixed so far is to change the “infinite” values, when they are found, by “By style” values, but we still need to figure out why these “infinite” values appear. Can you share one of your models? So far we had just noticed this in slabs in one specific file, but not on other objects.
Actually - that would fix my problem I think.
But anyway - here’s the model. (sending a wetransfer link because its 20+ MB)
Btw - I’m not sure if this is the best way to fix this because this fixes the ‘infinite’ value issue only when the ‘by style’ value is desired one, but if I changed one of the values to the custom one, that will be overwritten by the ‘by style’ value and I will have to manually check and figure out all the custom values again… Can you fix the code so it replaces the inifinite values with ‘custom’ values as well?
Also - your fix works only for slabs. When I update model, columns still get ‘infinites’ plus wall cleanup radii also get ‘infinites’ as seen below:
Hi @Sven_Duplić,
This is Enric Marques, a VisualARQ developer.
I’ve been investigating this issue for the last couple of days. I have concluded that the problem is related to an optimization that we do when a document is saved to reduce disk usage: we try to save numbers using a 32-bit precision floating number, when possible, instead of a 64-bit precision floating number. More in detail, we just try to convert the 64-bit value to a 32-bit value, and if the CPU doesn’t report a warning that the conversion is not perfect, we save the 32-bit value. And guess what? We internally use a “magic” number close to -infinite as “By Style”. So, it seems in some cases, this conversion does return a different value, but the CPU is not reporting the loss of precision. I don’t know if this is a problem on some CPUs, recent OS update, or that other plug-ins are modifying the CPU floating point control. This optimization code has been in VisualARQ for more than 10 years, so I guess something recent has broken this for our code.
I’ve improved our code, so now we’re also comparing the converted value to the original one, so if there is a loss of precision, we’ll still use the 64-bit precision number.
If I’m right in my conclusion, this will never be an issue, as overridden values are not “close” to -infinity.
After checking all code, the error will always appear when a document is saved, closed, and reopened. An opened document should never be “corrupted” while working, unless you save, close, and open it again.
With our fix, corrupted files are fixed when they are opened.
VisualARQ 2.13 will be published next week. If any of you want to try it, or urgently need a fixed version, we can send you ans installer right now.
Thanks,
Enric
Thanks for the effort! Since I’m working on a project right now, I’d very much appreciate the fixed version right now.
.NET CLR doesn’t have a fpstrict mode and guaranteed FPU write-back (JIT may even ignore conv.4/8). I have been running into issues possibly due to that. It’s also possible a result of recent CPU microcode updates.
I’ve just sent you an internal version by private message.
@Sven_Duplić , @Martin_Johnson Yesterday we released a new VisualARQ update 2.12.6 that fixes these errors of the “minus infinite” value. VisualARQ 2 - Version 2.12.6 released
Please, uninstall the internal VisualARQ 2.13 version you may have before installing this update.