the problem was that as soon as animations are exported the Exporeter enforced the decomposition of Object matrices into Location and x/y/z rotation. It looks like this decomposition is obsolete, so i removed it. Now the export/import of the scene seems to work as expected.
That was not a typo, it's this definition:
The difference is that Cycles uses the standard assert() which will abort, while Blender uses BLI_assert() which doesn't. I guess building with WITH_ASSERT_ABORT is ok. For the popups D2850 is a solution.
Hiding edited object has never been allowed, no bug here, this is expected behavior.
Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
There seems to be some varying behavior with asserts. This one silently failed while marking the test as succeeded, T52853 displayed a popup (abort to quit, retry to debug, ignore to carry on) which blocked further tests from running, given running ctest on a debug build took around 2 hours, not having to baby sit incase any ui shows up would be prefered. I'm not overly picky with any changes here, if WITH_ASSERT_ABORT does the trick i'll happily add that to my debug builds.
Our asserts by default do not error, only print the warning, autotest has nothing to do with that… There is a switch to actually abort on failed asserts iirc, could be useful to enable it for testing (can't remember exactly how, build option, envvar, …).
Right, it will only crash when building with WITH_ASSERT_ABORT. Not sure what the best way is to solve that, perhaps a --debug-abort command line option to enable aborting at runtime?
While the assert might not be auto testing related I really wish that this test wasn't marked as a pass, if i hadn't been randomly paying attention to the terminal, this would have just scrolled by and marked as a 'pass'
Am not sure what to say here… Yes, file is totally corrupted re libraries, no idea how this happened, and would need precise steps with basic simple files to reproduce such situation to go any further.
Indeed, there’s nothing we can do here, there is no regular FBX material stored in that file. We only have a big blob of binary data that could be pretty much anything, and mysterious material indices, but no material. So afraid we cannot do anything here.
After testing many versions, Bug is already present in 2.74.
I figured it out, and yes, going to TweakMode helped!
What is TweakMode and how do I access it?
Have you tried the latest Buildbot builds?
I had a similar bug that was fixed some time ago: https://developer.blender.org/T52479
I can confirm that in 2.79 official release 64bit that's is the behaviour. In Edit Mode you cannot hide the object currently being edited but you can hide other objects in the scene while you're in Edit Mode. It was the same in 2.78 and previous versions.
i attached video related to this error
please check if this is a bug above,in other programs,i can hide objects in layer in edit mode.
that’s not what I’d call 'simple file'… :/ Did you try to reproduce the issue with very basic set of files (mere cubes groups...)?
- As you have noticed, the language we use on this tracker is english not german.
- This is a general support issue and not a software error we can investigate.
Sounds like someone has been messing with order of datablocks during file save or reload… But as always, need simple .blend file to reproduce and investigate.
I have created two new reports.
Hope these can help. If you think I can send anything else that can help please dont hesitate to write.
Yes, but it's been like that for eons. Possible because in 2D 'Y' is up, and 3D (blender and others not to mention CNC) Z is up.
Anyway, to change it now would break all files back to 2.46.
Not a bug, sorry.