Thanks for the report, but text “meshification” leading to terrible topology is very old know issue, nothing new here, that is not considered as a bug currently.

Note that this affect other modifiers too (shrinkwrap and simple deform at least).

This is actually a bug in our defvert_array_find_weight_safe(), which was assuming that having a valid vgroup index but NULL vgroup data pointer was same as not having a valid vgroup index, and was returning '1.0' in both cases.

Thanks for the report, but I don’t actually see a bug here - maybe some inconsistency between two rather different tools, but that’s all. Harmonizing this would be a TODO (and it would be slightly hairy too, to avoid old files suddenly starting to behave differently).

Thanks for the report, but no bug here, it’s just psys that needs to be 'kicked' again to be recreated, touching to some modifier visibility (or adding a new one) is a way to do so, but you can also e.g. add a particle/hair to the count, etc.

Users of Blender are assumed to be technical enough to understand that computers are not magic black boxes that do all they want, and do have their limitations. We are not magicians. And we already get loads and loads of invalid bug reports about known limitations from both our own code and plain generic computers ones, this is not gonna change anyway.

Hmmm, afaik by default the Not TC In Use option is set for timecode, which means you are not using it. Typically, you’ll want to try with Record Run No Gaps option (same panel, below the proxy settings). Then rebuild proxies/timecodes, and check if issue is still there?

Hmmmm… this is way too late to add anything like that in master for 2.79 now… :/

arf, stupid stuff really, nothing wrong here, just that T2 is a valid task reference, so…

Thanks for the report, but indeed, scale does not work that way! It is stored along (local) axes of the objects, so when those are not aligned with selected transform space, scaling is merely proportionally spread across all involved object's axes. What you’d expect is actually converting scaling into shearing, which is not supported - and goes way beyond simple scale tool anyway.

Pfff… took me some time to understand the issue, because your vectors looked normalized at first sized - but yet, they actually were not normalized! Small difference, but as stated in docs, normals_split_custom_set() expects normalized vectors. This code works as expected:

Thanks for the investigations so far. :)

@Rohan Rathi (RohanRathi) might be interesting to implement support of custom normals in a few modifiers like triangluate, if you still have time in your GSoC?

Just doing undo/redo also works, or other things, like e.g. making camera child of cube after the ctrl-A action... Most certainly a missing update trigger.

EXCEPTION_ACCESS_VIOLATION means Blender tries to access invalid memory - typically already freed one.

@Roel Koster (kostex) rotations have the additional issue of always being multiplied twice in typical cases (conversion from degree to radian, and back to degree), since internally they are all stored as radians, but nearly always shown as degrees… This adds to the imprecision of things obviously, not much to be done here (except reducing again precision, which is not an option in that case).

Thanks for the report, but please keep in mind that 2.8 is still totally WIP, reporting known TODOs does not help us really, especially when we even took the care to add a message stating this is not working currently…

Crash report shows that you are using nouveau drivers, we only support official NVidia (or AMD, Intel etc.) drivers.

Good that we cached that before release, thanks!

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

That’s actually sort of a limitation of the format… thing is, when you export an armature not binded to any mesh, we do not have any bind data in FBX file - and bind data are closest thing we have to 'rest pose' of the armature, i.e. state in which bones are assumed to be by default. So when we re-import such FBX, we only have the current pose of the bone at save time to rebuild the armature - which leads to deformed (too or too short) ones. Then animation is applied on top of it, which was saved for actual rest pose…

I really need something simpler to investigate that whole rig with all the control bones, drivers, constraints etc. is really way too complex. It’s actually really complex for exporter even, for start. Might be related to T52039 actually, but kind of hard to say here…

Please follow our submission template and guidelines 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.

Please follow our submission template and guidelines 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.

Old depsgraph is detecting dependency cycles (you can partially work around it with usual 'extra relations' Object options), new one is working correctly, so thanks for the report, but no bug here.

OK, sooooo… On second thought (and much investigation) I do not think it's actually related to OpenGL.

On the other end, since '@' file is written first, would be the first one to hit permission issue, so…

Hmmm… the '@' file is a temp .blend file Blender uses to dump its binary data in, before renaming it to final file name - it avoids potentially running an existing .blend file whe you write over it.

Imho, if archipack wants to go in Blender-released addons, it should get rid of things like updater - we don’t want third party package-management-like things in our distributed addons…

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

Please always attach a small and simple .blend file to help reproducing the issue, always saves us a tremendous of time.

Well, in code main scaling for camera drawing explicitly only depends on ortho scale only for ortho camera… Maybe we could tempered that with object scale, as done with perspective camera, unless current behavior is done like that for a good reason, @Campbell Barton (campbellbarton) may know why?

Well, looks like this has been fixed somehow now? At least with current master when I select a preset from the menu, curve updates immediately…

Well… This is most certainly related to a specific hardware/driver/OS/software combination… Afraid we cannot help here really, feel free to keep communicating here if you manage to find more, but until there are some solid elements showing there is indeed a Blender bug involved, will close the report.

Thanks for the diff, we can close that task now then.

This is most certainly an issue with you local settings, like maybe your selection for temp directory or something similar… Message says it all really: for some reasons Blender has no permission to write on C:\ root.

Weird, as if scale was applied more than once…

Thanks for the report, but we do not support very limited platforms like raspberry pi at all - those are considered as waaayyyyyy to limited to run a modern Blender.

PointerProperty is not supposed to work in Operator at all (technically, we have no 'runtime' definition for Ppinter RNA property type).

Yeah, thanks for the report, but do not see any bug here, it is indeed expected that when you scale negatively, you get “inside out” mesh (that actually face winding, i.e. order in which face corners “turn around” face center, that get reversed, and imply reversed normals).

Please follow our submission template and guidelines 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.

Thanks for the report, but no bug here… Excluding shadow does not exclude geometry itself from rendering, so ti still affects amount of available light for specular, diffuse shadings, etc.

Difficult to help really without a simple .blend file to reproduce the issue, but two things to check:

1. Did you enabled AV-sync synchronization mode in TimeLine editor's header bar?
2. Did you generate valid timecode for your video?

Also, note that you cannot run 'replace image' on a packed one, this is not supported (and mostly likely, that’s why option is greyed out for you…).

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

Yep, thanks for the report, but this is indeed old known TODO.

Not sure we can do much here? It’s kind of Blender not having focus issue most likely, so it cannot handle own events, or something like that I’d guess… We need a windows dev to have a look at this, but would really no consider this as high priority issue.

Not squre what the issue is here, one way or the other unrendered layer is by definition invalid and more or less undetermined, random data… Changes in how we show here does not really matter imho? @Sergey Sharybin (sergey) should know better though.

Oh, did not saw latest comment… so crash can be replicated, and seems to be a Cycles issue, OSX-only maybe?

I cannot confirm any crash here. However, your custom font is missing from the file, so that may be the culprit - bad fonts can generate bad geometries and our font handling code is not advanced enough to always cope with those correctly, which can lead to crash. So please:

• Try the latest build from our buildbot.
• Try using another, more classical and well known font and see if it still crashes.

No bug here, just disable merge and clipping options of the modifier to avoid vertices too close to the mirror plane to be “altered” by the modifier. Thanks for the report anyway.

Thanks for the report, but don’t think this should be changed actually, this is supposed to affect normals as vertices ones, not really split ones…

Looks OK to me, someone else wants to double check (since we are rather close to RC1…), @Dalai Felinto (dfelinto) ? @Campbell Barton (campbellbarton)? @Julian Eisel (Severin)?

Thanks for the report, but this has absolutely nothing to do with linking - thing here is that pass ID of group instantiations is not used for group’s objects…

Thanks for the report, but don’t think we can do anything about that currently, proxy code and design is already a real problem to handle, and is due to be replaced by static override at some point in 2.8 series, so trying to hack around that is not really planned right now.

Well, sorry about your loss of work - but that’s just teaching you two important lessons:

• Always manually often save your work (like every minutes or so). Always.
• Read the manual when you have a problem - you would have then learned that Blender uses the 'shift-cltr-Z' convention for redo, not the 'ctrl-Y' one…

Thanks for the report, but this known and documented limitation - we do not support any nodal material, those are totally incompatible with FBX design, and trying to do some conversion from nodes to traditional 'fixed pipeline' shader is a nightmare and distant TODO… may be tackled some day, but definitively no bug here.