So i came across this little guy just this morning, i've been aware of these before, where 3drad has changed location and or orientation values it's self for no reason, but just noticed this one that anybody should be able to reproduce.
Of possible importance is using the key combo [CTRL]+[RMB] rotations on the object. The [CTRL] key enables "snapping" in 15 degree increments.
Take notice of the red box highlighted values being different !.
Also, which is valid, the object properties, or the 3deditor window, they both cant be right, and how would this effect our projects ?.
And does this also happen in your project, or is it just my computer ?
I included my project showing the error, but you can create this yourself as there is only 1 "buggycar" object in the project.
You should save this project without the ".txt" extention, but as it turns out, 3drad will load it with or without the .txt extention properly, just search for .txt in 3drads open file dialog.
@tinsoldier, the values in the property window are correct, but are just too small to be displayed in the scene view (you can see the exponent sign). This sort of thing can also happen in Unity (very annoying tbh).
@powersupersport you're saying -3.** -5.9*** -1.** are to small ?? that doesn't make sense.
@athanatos Well, i played a little more, now i have 7.** error showing in one of the location box's.
I do remember some time ago where fernando mentioned math errors can happen... but this error has in the past been worst than just a math error, where a skinmesh model was moved off camera by error values, probably the same issue, just way worst in that case.
It has to be an issue with 3drads math process's cause 3dsmax deals in extreme big and small objects and i've never seen this type of math error, not even once.
@tinsoldier, floats work like this. If the number is too big / too small, it will be displayed with an exponent sign. There are some numbers after that (e) sign that I just can't see from the screenshot you posted.
Let me explain. Take this number: 0.000000003. It has 8 zeros (9 symbols after the decimal). Converted to a number with an exponent sign it becomes 3.0e-9. The e-9 means 9 symbols after the decimal.
That's why I told you that the number is actually very small. Because when floats become too small / too big, their decimal point starts to move (precision gets lost) and they also start being displayed as an exponent representation. That's why it's called a float. It's decimal point "floats".
Take into account that a float takes just 4 bytes. It's invented to be capable of storing "generally large" numbers which don't matter in precision that much. An integer (int) for example is also 4 bytes, but can only store up to 2 147 483 647 (positive and negative).
@powersupersport your explanation still doesn't make sense to me and what i see.
But, what is or isnt displayed and what it means isnt the problem here, the fact that there is a number other than 0.00000 in both windows is the problem.. they should be the same value but are different.
If the object rotation in the editor is correct, then it's fine, it's just the floating point numbers accuracy issue. Accuracy is often keept the same as default because using the double precision points or quadruple precision points (in C++ it's long double (See this : https://en.wikipedia.org/wiki/Long_double )) will reduce performance, and the accuracy gain is not worth it.
@tinsoldier, the value you see in the scene view is just rounded to the closest second decimal (0.063 => ~0.06, 0.025 => ~0.03). That's why a number like 0.000000003 (3.0e-9) would just get rounded to 0.00. And that's ultimately the value you see in the scene view.
And as I said Tin, this is not a 3D Rad bug (for once). It happens in Unity too (and I assume in all game engines and programs that use floats in general).
I recently downloaded Intel Inspector. And ran a an advanced search for memory issues with one of my games. The memory issues were too nany to count. Incorrect memory allocation and deallocation, memory leaks etc. And most of them were to do with 3d rads dll libraries . All the pyshics dlls had errors.
I dont know what most of that means, but it raised alot of concern from my side.
But the least thorough search didnt pick up any errors. Just that one afvanced searched popped up a couple thousand errors.
@kulu, this should've probably been in its own thread, but anyway...
No one has ever been concerned about the memory management of 3D Rad. I have never tested myself how it performs. I don't even know if 3D Rad has a garbage collector (to clean up the memory allocated by the custom scripts).
3D Rad hasn't had an update since 2012, therefore it's absolutely expectable that it would have memory management problems as they haven't been addressed since then.
As for your games right now, there's nothing too much you can do. There aren't any tips/docs on how to manage memory in 3D Rad.
There aren't any tips/docs on how to manage memory in 3D Rad.
It's Fernando fault for filling 3D Rad with bad code. Allocated memory in the heap should be always freed, while the stack is automatically cleared. And that's a fudamental rule when programming in C/C++.
Well the only bug that kills my projects is the memory usage one. 3d rad seems to run faster and longer (loading and unloading multiple scenes) only when the shaders are redused to mostly the default shader. It's exactly what I did with caged photon, to get it to not crash. Every solution for memory problems is to add c++ code to the program. But since the soutce code for 3d rad is no where to be found, theres no reall way of fixing it. Although, I did see a reference to memory allocation and deallocation in the 3d rad scripts reference, from 3d rad boards.net . The scripts were for loading and unloading shaders and dlls. But then again even though it said that 3d rad deallocates memory for shaders and dlls when it exits a scene. It said that it's good practice to deallocate memory through a script. But I havent tried it yet. :/