Activity Feed

Hi @YAFU, right away, this isn't a bug, this just isn't supported technically. After having a quick look at the code, I think copying an object stores data on the hard drive so that it's accessible from another instance of Blender. Copying nodes uses a completely different - internal - technic, so AFAIK it's not really possible to access this from an external program. The same applies to masks and tracking markers btw.

Bug_line.blend1

I would actually be quite skeptical about accepting 2x memory usage. For my knowledge ghash could be used for quite heavy meshes, in which case it's really problematic to increase memory consumption. It also feels a bit weird to have hash in the entry itself. It feels after all the changes you did there should be no so much hash/values comparisons and if it's still an issue i guess we need to look into particular hash/comparison functions and optimize them instead. If it's not possible and storing value will really help we can store the hash for those particular ghashes in user key?

Unfortunately, the backtrace is not really helpful because it indicates where the issue was reveal, not when it actually happened. Actual issue happens somewhere prior to that point and it's causing corrupted geometry.

• Merge branch 'master' into temp-ghash-experiments
  • Factorize gset/ghash add/reinsert functions.
  • GTests GHash performance cleanup (strictly one test per GTest).
  • Cleanup (reduce a bit passing size of entries around by storing it in ghash itself).
  • Making hash storage optional.
  • Merge branch 'master' into temp-ghash-experiments

This just makes it so Alt+RMB selecting always selects the entire interior loop.

I just double checked but I don't see that happening. Alt+RMB isn't affected at all as toggle is false then and Shift+Alt+RMB works in an acceptable way, IMHO:

• Rename variable to start_time.
• Move print a bit further below, as there are still the marginal CDFs calculated. Print should reflect whole build time.

Grrr, sorry, missed a few things while cleaning up…

I have to agree with Bastien after some thought. Looks like reporter expects that the setting in the scene is the setting blender exports at but that is not how it usually works with exporters, rather we make sure to export at the base unit (which is meter), so scaling is correct. If you want the data to be expressed in millimeters use the scaling factor in the exporter. As explained, previously this worked by accident mostly.

Once and for all: STL has no unit. Henceforth, there is no 'correct' or 'incorrect' scaling when exporting. User has to define itself which unit he wants his STL to be in, and set scaling accordingly.

I have to agree with reporter here.