Heavy modified Linux Mint17 and 13 with newest and older Nvidia Drivers
Asus G73 with 2GHz Sandybridge Quadcore and a Nvidia 460m GTX (Doesn't work)
Acer AO 725 with 1.33GHz Dualcore and AMD Onboard Graphics (Doesn't work)
Medion Erazor with 3.4GHz Ivybridge Quadcore and a Nvidia 870m GTX (Works with minor lags)
version 2.75 (sub 0), branch b'master', commit date b'2015-06-19' b'14:59', hash b'c85a58a', b'Release'
version 2.69 (sub 0), revision b'unknown'. b'None' (From Mint/Ubuntu)
version 2.68a Release from your old blender repo
Worked: Like the most other Constraints never as far as i know!
Short description of error
At first, i have read all the constraints problems (if they had a promising title) till now that i could find, also the ones in "to do", but this terrible one i didn't found anywhere, so have a good look at it please, even if i could not believe, that no one ever had a problem with that, since it is so basic and i don't believe, that everyone out there has much more than a 2GHz quadcore...
My Asus G73 Gaming Machine with 2GHz Quadcore&NV460GTX and of course my little Acer AO725 are "too slow" to calculate a stupid single "Copy Location" Constraint in Blender, but a 3.4GHz Quadcore does the Job somewhat, so hopefully you don't want to tell me, that 8GHz is not enough to pass over XYZ Positions from one Object to another, else i would suggest to finally get rid of the so lame Python Stuff!
WARNING, I AM THE “EVIL” GUY WHO ALWAYS INJECTS USEFUL FUTURE POINTING IDEAS AND SOME UNCOMFORTABLE REMINDERS IN HIS BUG REPORTS, BECAUSE HE SERIOUSLY BELIEVES, THAT THE SOMETIMES EVEN WORKFLOW KILLING DESIGN FLAWS IN BLENDER AND THIS EVER ONGOING "NEWS RUSH" WITHOUT PERFECTIONING WHAT WAS ALREADY THERE AND ESSENTIAL, IS MUCH MORE ANNOYING, THAN ANY "BUG" BLENDER EVER HAD(I'm on the boat since the first versions appeared on GNU+Linux, so quite a while)!
Therefore, if you are a that much single threaded pragmatic "BUG" hunter, that these maybe highly valuable informations from an very old blender user would be a torture for you to read, GOTO line 21(In other terms after the bigger gap.. fuck, this website only allows one empty newline, you're on your own dude!:D:D:) and for the rest please post a link to the great chief or someone else who has probably more future-buffer capacity at the moment ;)
//Declaration of good intentions in coming "critics"
Hello dear blender staff, just to clarify that i am not only here for "rantings", i at first wanted to say a BIG thank you all for this genius piece of software, specifically the modeling part which i would declare the most uncompromisingly usable and almost perfect thing ever created in human history. :)
//Some exceptions and important suggestions to the compliments above:
The only things that are still a bit annoying at modeling, are the B-Mesh "hallucinations" which i already posted
Sadly to just get shoot down as invalid post! But since i still always get filled my head from blender newbies about that, and they even believe that blender modeling is crap because of that, what could not be further away from reality, i really even for my own humble opinion, have to insist, that blender should really get rid of this "B-Mesh Quad Plane Hallucinations" by just automagickally(or optional but unlike CTRL+T always?) triangulating every such plane that crosses that point where it makes that hallucination. Too see what i mean, open the link above or for a new very simple example, just grab the top right edge of a cube and drag it in the direction of the bottom left, what is exactly the first experience a blender newbie often had(Maybe a cheap hack would be to change the cube to suzanne per default), by just playing around with what is there and if such a stupid "hallucination" then occurs in that first moment, they may just think "boeh, they must have too crazy shit in their coffeeshops down there" and then they probably leave blender...
My idea of rotate able normals(must not be normals, could also be an additional direction pointer), at least on edges, which would made technical modeling(or even bumpmap or particle effects) much easier when we could move directly and precisely in a specific direction angle, or even a tool which allows directly to bend a plate which then maintains its thickness after the bending angle, as well as my old suggestion, to make the edge and face info also individually scale able, just like the indication lines of normals, is sadly still not implemented to this day and would be very essential for people, who do technical plans with blender, and i guess also it would not even be that complicated to implement(At least compared to all this high-tech but low usage visual gimmick tools blender always gets... Stone age mentality i know, but after WW3 we will see again, what serves best, appearance or functionality :D)!
//Reinitialisation of important stuff that is closely related to the main BUG reports that will come next:
Any way, most of the problems with the BGE and even animations or interactive interactions in Blender Render Mode, is due to the obvious fact, that Blender sadly rots from the inside, as most of the effort seems to go only in attracting peoples with superficial graphical gimmicks, while the most important essential things like constraints and some other technical functionalities, seem to be a totally broken crap(i know, you just model humans/animals with bones and you code every thing else in python, what may work reasonably well, so you are probably not interested, but in this case, then just remove these constraints or place a big warning, that they are just for very simple tasks and will not work for technical complexity or probably not at all) or are just utterly useless, with that i mean, they lack the simplest stuff like,
---->"what if i want to influence more then 1.0?"
---->"why do i have to switch UI to work with drivers and their by the way incredible stupid syntax(what's the sense being forced to write an "empty" >else< in such a small field, if there is no need for one?! The “true if” way is meant as a bad joke, isn't it?0.o), when in most of the cases it would be enough, when these constraints would have a field, where we could see their value and directly inject custom formulas on top of that?"
---->"why to hell i have to trick around with so many constraints only to achieve some sort of bidirectional influence between objects, or why we even just had this parent->child only behavior, that is not much real world orientated and just creates these dependency cycles(I know, for such jobs we should use bones with inverse kinematics, but i hate them, because they give much more work to place them well aligned with their ever occurring boneroll ghetto, the extra need for axis restrictions to stop them from going where they want gives more work too, what is not that funny, if you modeled a "Machine" with nearly 2000 complex mechanical parts like i had for a friend of mine over several years now)"
//Congratulations, this is the first "BUG" in my decades of blender experience, which i couldn't find an easy workaround for, so i guess it is more a kind of design flaw, because it is so terrifying(I would really suggest to rather open a design flaw tracker!)
//Clear evidence of the constraints problem in File 1
In the last second, when all this here was already written, i discovered on a extern gaming laptop(With a exact dd copy of the OS on which the problem occurs on the Asus G73 where I am currently working on), that it doesn't show up so extreme on a 3.4GHz ivybridge quadcore, except when running in software renderer, but hey, i don't believe, that my Asus G73 with a 2.0GHz sandybridge quadcore in maximal performance mode(CPU+GPU with new and activated Nvidia Drivers), which played Modern Warfare3, Battlefield3 and Hitman Absolution(With lotta "Copy Location" from dead bodies:D) without a single lag, should not be enough to handle a goddamn simple „copy location“ and 20 parented objects from blender, something must be terribly wrong with your constraints or even deeper stuff, since it reacts the same way with custom drivers, that copies the location with their code!)
In the other examples the problems may be circumvented with a proper armature and inverse kinematics, but for this one i don't know an alternative setup nor would i find it that "sexy" to do it with bones somehow.
With only these parts i provided in File 1(my "client" want to patent his machine first, so i am not allowed to show more) the setup i made, seems maybe like utter nonsense, but it really had to be that way and i have lots of parts which creates cycles in dependencies, which blender seems not be able to handle right or obviously at least not fast enough.
At first i thought that it is only the viewport that is so lame and that it won't show up in the renderings, but there it was also, even at relative slow linear speeds, what is a very terrifying finding after 3-4 years of modeling a machine, that has nearly 2000 parts... By the way, in animation playback, i got the meanwhile older Asus G73 gaming "rocket" with a NV460GTX i am currently working on, almost to its knees(~17FPS@30FPS NTSC) with these nearly 1'000'000 vertices and nearly 2'000'000 triangles in the big project, so i wanted to ask, if blender has some occluding and frustum culling techniques already in the render mode viewport, or if it wouldn't be nice to implement such things, especially for such important cases, rather then even more visual gimmicks like SSAO?
Already done Tests:
01. As we can see, i already enabled the "extra update" buttons everywhere, but there is no difference without them.
02. It even doesn't matter if we enable the drivers, so it must be clearly the constraints or even deeper underlaying things.
03. I tried already to replace all the "copy location" constraints with drivers, with the same results, so it must be even deeper than just the constraints.
04. The interesting part is, if we just delete the "ESH(Z)SaeulenSpindelKleinMitnehmerscheibeMitInnen4K.(15x15)" which has absolute no relevance except that it is parented to the same parent, all works relatively acceptable(If zoomed in after a fat move, stuff isn't aligned 100% right, but for a animation with a distant view on the machine well enough for me), but it has not specifically something to do with this part, more with how much children are parented to a parent and how complex their geometry is, what i know, because this part of the machine has much more complex parts and the effect is, that the mentioned "ESH(Z)RatscheGriff" part and his children drags much more behind, the more other parts are parented to the parent object(ESH(Z)SaeuleVierkanntStange.05).
05. Another less interesting test i made, was to set all origins to the same point, in hope there is less difference to calculate or something esoteric like that, but the result was that just all the other parts then started to drag behind instead.
06. As noted in the beginning, the last test i made was on a other much faster laptop and there it works relatively good(At least this little test file here, more of the big project i can't test on it, because it is a gaming machine with Steam on it, in other words not trustable for „business“ projects even if it is a Linux OS) with the Nvidia Drivers, but the same problem arises if i switch to software render, so your constraints are way too CPU demanding for that little „Copy Location“ task!
07. Another maybe helpful point is, that on the Asus G73 Laptop which is "too slow" for the simple constraints as mentioned before, the "task manager" never shows any significant load, even if i move the stuff around as fast as i can, on the other hand, the much faster Medion Erazor Laptop also shows no load whilst doing this, but the CPU-Freq-Indicator raises to the full 3.4GHz, what he never does elsewhere in normal use, which lays around 2.5GHz most of the time on blendering or youtubing tasks, so it is no CPU load problem, but the amount it can get at once!
//Clear evidence of the constraints problem in File 2
(Same here, 3.4GHz quadcore relatively OK, 2GHz quadcore and the parts flap like a bird whilst moving along the Y-Axis).
A right mouse button canceling even end in a visual disaster, all parts align and place themselves random!
(I know, such things should probably be done with armatures and inverse kinematics, but i hate bones and prefer the old-school way, at least when it would work as expected!)
//Clear evidence of the constraints problem in File 3
(For this Rostock 3D Printer simulation i tried to make last year or so, even a 3.4GHz quadcore isn't enough any more to hold the arms in a stable position!).
(I know, such things should probably be done with armatures and inverse kinematics, but i didn't have the time to experiment with them, is there any Bone-Guru here, who is very sure, that this up/down movement of the carriers from a side pressure will also be possible with bones, or maybe i'll better ask more generally, if everything will be possible like all the stuff i dirty hacked with empties, constraints and so on, will work well/better with bones too?)
There were other blender users too, who obviously had the same constraint problems as they tried to make a Rostock 3D Printer with these lousy constraints!