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. :/
interesting find kulu, but mem leaks are usually not an issue unless the user runs out of available free ram. in the case of your recent MP FPS it only uses 1gb, while my win7 also uses 1gb, so unless you plan on running on 2gb pcs, freeing even a few 100mb leaks [i doubt it would even be that much] won't make any difference to the 2gb+ free ram even minimum 4gb gamers should have these days.
the reason shaders cause you issues is you have too many objects on screen [each visible face needs it's lighting calculated -even those distant chairs and tables in every room when the player is outside] that's why games use LODs.
interesting find kulu, but mem leaks are usually not an issue unless the user runs out of available free ram.
No. As a programmer you shouln't take memory leaks as something minor :
Oh nevermind, it's just a single memory leak when allocating memory for let's say, a Skinmesh object.
Memory leaks are always bad especially with bigger programs for example an IDE, a game engine,etc. We shouldn't take some sort of decision algorithm if we can decide if we should or shouln't fix a memory leak.
First of all let's define a memory leak.
By the common definition, a memory leak occurs when the program/code/assembly/etc is allocating dynamic memory and not releasing it. This is a example written in C:
//Note: this code was tested using a online compiler, try it yourself.
int s; //Define a simple integer value
float *v = (float*)malloc(sizeof(float)*s); //create a float array with the size of s.
scanf("%i",&s); //We read it
//We read the array
for(int i =0 ; i < s;i++)
printf("\n displaying array ");
for(int i =0 ; i < s;i++)
printf("v[%i] = %f ",i,v[i]);
By definition, I made a memory leak, but that leaked memory is going to be freed by the operating system when the application execution stop. That's the reason why also my programming teacher told me not to take memory leaks seriously. And I disagree.
The reason I disagree is because by not worring about a single memory leak, like in the C console application I written, you will forget and/or not care about the small memory leaks that add up in a bigger application.
Also, by common definition I mean the widely understood definition. There's a thing I think that's commonly missed. Unfreed memory that is going to be used later is not a memory leak. For example, look at this C++ example:
char* MyString(int length)
return new char[length]'
char *s = MyString(5);
delete s; //Not a memory leak, we freed that memory.
Now the fix for a memory leak is freeing dynamic or shared memory that isn't being used anymore, as seen above.
In conclusion, memory leaks can be taken as a sign of incompetence, lack of experience, etc.
As a user, you can only 'detect'/see memory leaks in Task Manager or in some fancy softwares.
has has anyone actually measured how much ram 3drad is leaking over time then? i ask this as i am 99% sure fixing that would not resolve it's performance issues, it has more to do with internal clock sync between graphics and physics, which fortunately i found a solution for.