2.75RC2 and all Blenders below, have terrifying bad Constraints, not even the simplest "Copy Location" works, or at least demands a 3.4GHz Quadcore! #45194

New Issue

Mad Overlord · 2015-06-25T16:53:15+02:00

Mad Overlord commented

2015-06-25 16:53:15 +02:00

System Information
Heavy modified Linux Mint17 and 13 with newest and older Nvidia Drivers

Tested Machines
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)

Blender Version
version 2.75 (sub 0), branch b'master', commit date b'2015-06-19' b'14:59', hash b'c85a58a', b'Release'
down to
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!

01 - BLENDER 2.75 BUG - Position actualisation is much toooo slow.blend

02 - BLENDER 2.75 BUG - Position actualisation is much toooo slow.blend

03 - Interactive Rostock Design Test(750mm Arms with Dumped Track and everything X+Y transform locked on a 70cm Diameter Curve).blend

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!

//Descriptor
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
https://developer.blender.org/T34433
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:

As we can see, i already enabled the "extra update" buttons everywhere, but there is no difference without them.
It even doesn't matter if we enable the drivers, so it must be clearly the constraints or even deeper underlaying things.
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.
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).
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.
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!
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!
https://www.youtube.com/watch?v=2YreANHtnSo
https://www.youtube.com/watch?v=Q0KYdkvBQJ0
https://www.youtube.com/watch?v=t0MeQcjzlSc

**System Information** Heavy modified Linux Mint17 and 13 with newest and older Nvidia Drivers **Tested Machines** 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) **Blender Version** version 2.75 (sub 0), branch b'master', commit date b'2015-06-19' b'14:59', hash b'c85a58a', b'Release' down to 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! [01 - BLENDER 2.75 BUG - Position actualisation is much toooo slow.blend](https://archive.blender.org/developer/F197338/01_-_BLENDER_2.75_BUG_-_Position_actualisation_is_much_toooo_slow.blend) [02 - BLENDER 2.75 BUG - Position actualisation is much toooo slow.blend](https://archive.blender.org/developer/F197339/02_-_BLENDER_2.75_BUG_-_Position_actualisation_is_much_toooo_slow.blend) [03 - Interactive Rostock Design Test(750mm Arms with Dumped Track and everything X+Y transform locked on a 70cm Diameter Curve).blend](https://archive.blender.org/developer/F197340/03_-_Interactive_Rostock_Design_Test_750mm_Arms_with_Dumped_Track_and_everything_X_Y_transform_locked_on_a_70cm_Diameter_Curve_.blend) **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! //Descriptor 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 https://developer.blender.org/T34433 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! https://www.youtube.com/watch?v=2YreANHtnSo https://www.youtube.com/watch?v=Q0KYdkvBQJ0 https://www.youtube.com/watch?v=t0MeQcjzlSc

Mad Overlord commented

2015-06-25 16:53:15 +02:00

Changed status to: 'Open'

Mad Overlord commented

2015-06-25 16:53:15 +02:00

Added subscriber: @mad-overlord

Antonis Ryakiotakis commented

2015-06-25 17:48:28 +02:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis commented

2015-06-25 17:48:28 +02:00

Changed status from 'Open' to: 'Archived'

Antonis Ryakiotakis closed this issue

2015-06-25 17:48:28 +02:00

Antonis Ryakiotakis self-assigned this 2015-06-25 17:48:28 +02:00

Antonis Ryakiotakis commented

2015-06-25 17:48:28 +02:00

Hi, first of all, keep bug reports short and to the point. We do not have the time to read this wall of text, nor read rants about the older bug report (which was correctly closed) or each person's vision for blender.

All your files have dependency cycles but they do not really run that slowly here. Dependency cycles means that there is no really correct order of evaluation so it's expected that they will break. It's up to you to fix your rigs not blender.
Dependency cycle warnings appear when you run blender from the console so you might have some easier time fixing the rigs.

Since rigs with dependency cycles are known to fail I will be closing this as known limitation.

Hi, first of all, keep bug reports short and to the point. We do not have the time to read this wall of text, nor read rants about the older bug report (which was correctly closed) or each person's vision for blender. All your files have dependency cycles but they do not really run that slowly here. Dependency cycles means that there is no really correct order of evaluation so it's expected that they will break. It's up to you to fix your rigs not blender. Dependency cycle warnings appear when you run blender from the console so you might have some easier time fixing the rigs. Since rigs with dependency cycles are known to fail I will be closing this as known limitation.

Antonis Ryakiotakis commented

2015-06-25 17:50:46 +02:00

Changed status from 'Archived' to: 'Archived'

Mad Overlord commented

2015-06-25 22:49:09 +02:00

In #45194#317596, @Psy-Fi wrote:
Hi, first of all, keep bug reports short and to the point. We do not have the time to read this wall of text, nor read rants about the older bug report (which was correctly closed) or each person's vision for blender.

All your files have dependency cycles but they do not really run that slowly here. Dependency cycles means that there is no really correct order of evaluation so it's expected that they will break. It's up to you to fix your rigs not blender.
Dependency cycle warnings appear when you run blender from the console so you might have some easier time fixing the rigs.

Since rigs with dependency cycles are known to fail I will be closing this as known limitation.

Yeah, but you obviously have too much time to implement that much super duper ever crashing visual gimmick and even for all the crapple "appearance is all" Justins with no idea, which are yelling about stuff, that i just get bloody facepalms off, because it could be circumvented relatively easy compared to inherent DESIGN FLAWS we suffer since the beginning, that is phantastic, or should i rather say surreal...
Very sad, that you didn't take the time to read, because i have already said all what is important, and the content of your sadly not that helpful answer is very clear to me(I AM A LINUX FREAK, I KNOW WHAT A TERMINAL IS, TRUST ME ;D And i am also a prehistoric blender user, i am on it since the earliest releases for Linux over a decade ago), but that did not solve the problem, that blender has a inherent stupid(sorry i really don't intent to harm anyones little feelings by such harsh words, but also that i declared in my wall of text you didn't read)internal architecture since years now and obviosly no one that took the time, to investigate that with the right eyes, and my "blabla" here is quite a good and deep investigation i think, because the idea on how to stop it, is the result of many years of suffering on these design flaws(No wonder it was not short as "Hi, i am John and i have a BUG, just as we all do)!
I know from other BUG reports here that you have to deal with quite a lot idiots, but even if i sometimes hardly try to be the greatest, i probably failed this time, because it really is as i posted!
May i ask what the specs of your hardware was, on which you tested my stuff? If too high, have you tested "Software Rendering" as i mentioned? Because i can reproduce this on any machine i get my hands on, if the CPU isn't a hardcore gamer rig, but way good enough to just COPY a damn single location in realtime if the programmer would have done his job(or even better his hobby)right and even more crazy is the fact, that this shit also appears on renderings, what i honestly can't understand at all! And as i have stated in my "blabla" here, THERE ARE SETUPS, IN WHICH YOU CAN'T AVOID DEPENDENCYs, because this is how reality is, there is no such thing as a Parent->Child only dictator relation ship, a linear world to nowhere only exists in the worlds economys wet dreams, there are also bidirectional relations, unbroken circles, the snake which bytes his own ass man and for which stupid reason this may be, blender covers them maybe just with bones and ik, but that is not so useful in many cases and for pre armature/bones people genarally not!

Since BUG hunters with too pragmatic minds are known to fail, i plead to reopen this as known limitation ;)
(Aaaha, a little search showed me, that you are mostly involved in things i often harshly called visual "gimmick" in my wall of text, so maybe you were not the best one to decide about what i said here about constraints, and let me guess, you were just pissed off, that i worship functionality more then appearance?0.o If so, make a real in blender 2D paint software(with the usual blender shortcuts), which frees us from this stupid Gimp, as i also mentioned from time to time, and i would also kiss your ass mentaly, if you need that so much ;) )

PEACE MAN

> In #45194#317596, @Psy-Fi wrote: > Hi, first of all, keep bug reports short and to the point. We do not have the time to read this wall of text, nor read rants about the older bug report (which was correctly closed) or each person's vision for blender. > > All your files have dependency cycles but they do not really run that slowly here. Dependency cycles means that there is no really correct order of evaluation so it's expected that they will break. It's up to you to fix your rigs not blender. > Dependency cycle warnings appear when you run blender from the console so you might have some easier time fixing the rigs. > > Since rigs with dependency cycles are known to fail I will be closing this as known limitation. **Yeah, but you obviously have too much time to implement that much super duper ever crashing visual gimmick and even for all the crapple "appearance is all" Justins with no idea, which are yelling about stuff, that i just get bloody facepalms off, because it could be circumvented relatively easy compared to inherent DESIGN FLAWS we suffer since the beginning, that is phantastic, or should i rather say surreal... Very sad, that you didn't take the time to read, because i have already said all what is important, and the content of your sadly not that helpful answer is very clear to me**(I AM A LINUX FREAK, I KNOW WHAT A TERMINAL IS, TRUST ME ;D And i am also a prehistoric blender user, i am on it since the earliest releases for Linux over a decade ago)**, but that did not solve the problem, that blender has a inherent stupid**(sorry i really don't intent to harm anyones little feelings by such harsh words, but also that i declared in my wall of text you didn't read)**internal architecture since years now and obviosly no one that took the time, to investigate that with the right eyes, and my "blabla" here is quite a good and deep investigation i think, because the idea on how to stop it, is the result of many years of suffering on these design flaws**(No wonder it was not short as "Hi, i am John and i have a BUG, just as we all do)**! I know from other BUG reports here that you have to deal with quite a lot idiots, but even if i sometimes hardly try to be the greatest, i probably failed this time, because it really is as i posted! May i ask what the specs of your hardware was, on which you tested my stuff? If too high, have you tested "Software Rendering" as i mentioned? Because i can reproduce this on any machine i get my hands on, if the CPU isn't a hardcore gamer rig, but way good enough to just COPY a damn single location in realtime if the programmer would have done his job**(or even better his hobby)**right and even more crazy is the fact, that this shit also appears on renderings, what i honestly can't understand at all! And as i have stated in my "blabla" here, THERE ARE SETUPS, IN WHICH YOU CAN'T AVOID DEPENDENCYs, because this is how reality is, there is no such thing as a Parent->Child only dictator relation ship, a linear world to nowhere only exists in the worlds economys wet dreams, there are also bidirectional relations, unbroken circles, the snake which bytes his own ass man and for which stupid reason this may be, blender covers them maybe just with bones and ik, but that is not so useful in many cases and for pre armature/bones people genarally not!** **Since BUG hunters with too pragmatic minds are known to fail, i plead to reopen this as known limitation ;)** (Aaaha, a little search showed me, that you are mostly involved in things i often harshly called visual "gimmick" in my wall of text, so maybe you were not the best one to decide about what i said here about constraints, and let me guess, you were just pissed off, that i worship functionality more then appearance?0.o If so, make a real in blender 2D paint software(with the usual blender shortcuts), which frees us from this stupid Gimp, as i also mentioned from time to time, and i would also kiss your ass mentaly, if you need that so much ;) ) PEACE MAN

Antonis Ryakiotakis commented

2015-06-26 00:09:24 +02:00

Reminding again that the tracker is not meant as a frustration venting, feature request, theatrical prose or natural philosophy forum. Thankfully there is a multitude of sites on the internet for this kind of activity. If this goes on there might be some moderation. Please stick to the guidelines I mentioned in the first paragraph in my first comment for future reports. You can check other reports on examples on how to report a bug properly.

Mad Overlord commented

2015-06-26 05:01:01 +02:00

In #45194#317696, @Psy-Fi wrote:
Reminding again that the tracker is not meant as a frustration venting, feature request, theatrical prose or natural philosophy forum. Thankfully there is a multitude of sites on the internet for this kind of activity. If this goes on there might be some moderation. Please stick to the guidelines I mentioned in the first paragraph in my first comment for future reports. You can check other reports on examples on how to report a bug properly.

I am not frustrated man, this is just the way i am, i am just not that serious, as the first part of my name or even the whole may indicate ;)
And i also can't take this BUG tracker here that serious, because as i also said(probably a thousend times), any "BUG" blender ever had, wasn't that terrifying as the inherent design flaws, because they could be easy circumvented, by just stopping to do this, or changing to that value etc. BUT A DESIGN FLAW OR BASIC PROBLEM YOU CAN'T CIRCUMVENT MUCH and they last a damn long time and influence the workflow very negative, SO THEY SHOULD HAVE A MUCH HIGHER PRIORITY instead of such lousy little "BUGs", is that so hard to understand or can you, with your obviously big knowledge about websites in the eternity of bullshit out there in the internet, point me to the right BLENDER DESIGN FLAW TRACKER or at least the BLENDER RESTORATION-REQUEST, because all these funboards and feature-request sites are just a graveyard i suspect, and sadly blender will fall into it one day, if this hollywood mockup mentality continues. So take it a bit more easy please, seriousness kills slowly my friend and robot minds are robot slaves as ozzy once said very correctly!
And by the way, you didn't even aswered my question, about what the specs of your test hardware was, on which you allegedly didn't came to the same negative results?0.o

> In #45194#317696, @Psy-Fi wrote: > Reminding again that the tracker is not meant as a frustration venting, feature request, theatrical prose or natural philosophy forum. Thankfully there is a multitude of sites on the internet for this kind of activity. If this goes on there might be some moderation. Please stick to the guidelines I mentioned in the first paragraph in my first comment for future reports. You can check other reports on examples on how to report a bug properly. I am not frustrated man, this is just the way i am, i am just not that serious, as the first part of my name or even the whole may indicate ;) And i also can't take this BUG tracker here that serious, because as i also said(probably a thousend times), any "BUG" blender ever had, wasn't that terrifying as the inherent design flaws, because they could be easy circumvented, by just stopping to do this, or changing to that value etc. BUT A DESIGN FLAW OR BASIC PROBLEM YOU CAN'T CIRCUMVENT MUCH and they last a damn long time and influence the workflow very negative, SO THEY SHOULD HAVE A MUCH HIGHER PRIORITY instead of such lousy little "BUGs", is that so hard to understand or can you, with your obviously big knowledge about websites in the eternity of bullshit out there in the internet, point me to the right BLENDER DESIGN FLAW TRACKER or at least the BLENDER RESTORATION-REQUEST, because all these funboards and feature-request sites are just a graveyard i suspect, and sadly blender will fall into it one day, if this hollywood mockup mentality continues. So take it a bit more easy please, seriousness kills slowly my friend and robot minds are robot slaves as ozzy once said very correctly! And by the way, you didn't even aswered my question, about what the specs of your test hardware was, on which you allegedly didn't came to the same negative results?0.o

Ton Roosendaal commented

2015-06-26 12:11:53 +02:00

Added subscriber: @Ton

Ton Roosendaal commented

2015-06-26 12:11:54 +02:00

Everyone who works on Blender knows that there are myriads of unfinished features, half working features, old and unmaintained code and flaws in design that makes using Blender frustrating.

That is normal for any software project. To handle that we have the projects that run on blender.org - check "get involved". We welcome new developers to take ownership of parts or to solve issues. That's how an open source project works.

Thanks to our generous donations and sponsors we can also hire a couple of people to work on Blender full time. Their job is to work on the bug tracker (some do it half time or more), to do code reviews and help other developers, and to pick up the urgent to-dos on the maintenance list.

In total that's currently just 5 people. For a software project with half a million of downloads per months that's really a low number. And to see how much we get done, we can only be very proud of what we achieve here.

As chairman of Blender Foundation I'm responsible for assigning people tasks and to decide which developers get grants. I choose to first have the real bugs tackled in Blender, to make stable releases, and when there's time left to review patches and make sure new developers can get in. These tasks we can barely handle already.

If you want to help out here, then just report Blender bugs here, 100s of people do that here each week. If you want to get involved as a developer to make Blender better, check the 'get involved' section on blender.org. If you have money spare, decide to become a donator or to hire developers yourself. If you know how features should be better designed, write papers or designs on that online.

Everyone is here with a positive attitude to help making Blender better. But everyone here is also aware of the fact that nothing happens really because you want it - things only happen because you do it yourself, together with the others here.

Ton-

Everyone who works on Blender knows that there are myriads of unfinished features, half working features, old and unmaintained code and flaws in design that makes using Blender frustrating. That is normal for any software project. To handle that we have the projects that run on blender.org - check "get involved". We welcome new developers to take ownership of parts or to solve issues. That's how an open source project works. Thanks to our generous donations and sponsors we can also hire a couple of people to work on Blender full time. Their job is to work on the bug tracker (some do it half time or more), to do code reviews and help other developers, and to pick up the urgent to-dos on the maintenance list. In total that's currently just 5 people. For a software project with half a million of downloads per months that's really a low number. And to see how much we get done, we can only be very proud of what we achieve here. As chairman of Blender Foundation I'm responsible for assigning people tasks and to decide which developers get grants. I choose to first have the real bugs tackled in Blender, to make stable releases, and when there's time left to review patches and make sure new developers can get in. These tasks we can barely handle already. If you want to help out here, then just report Blender bugs here, 100s of people do that here each week. If you want to get involved as a developer to make Blender better, check the 'get involved' section on blender.org. If you have money spare, decide to become a donator or to hire developers yourself. If you know how features should be better designed, write papers or designs on that online. Everyone is here with a positive attitude to help making Blender better. But everyone here is also aware of the fact that nothing happens really because you want it - things only happen because you do it yourself, together with the others here. - Ton-

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

2.75RC2 and all Blenders below, have terrifying bad Constraints, not even the simplest "Copy Location" works, or at least demands a 3.4GHz Quadcore! #45194