- User Since
- Nov 28 2009, 10:22 PM (481 w, 15 h)
@Amir (Warrior), 2.8 is quite different in relations within dependency graph. Backporting this one in 2.7 might not be that trivial. Would rather spend all energy moving towards stable 2.8.
Also, this might be considered a breaking-compatibility change. Behavior is not exactly the same as in 2.7 (with both old and new dependency graphs).
Fri, Feb 15
While there are ways to support this in theory, we currently don't support such level of granularity. Longer term solution would be nodes i think, where it becomes more explicit what goes where.
Thu, Feb 14
@Campbell Barton (campbellbarton), yay for splitting the file!
I could revert this patch and remove for_render (or remove it's use for forcing evaluation of linked data), always using curve_cache, failing if it's not there.
Weird. Was looking for quite some time =\ Thanks!
Please always attach .blend file which demonstrates the issue.
This doesn't seem a correct solution to me. Evaluation should not keep track of dependencies, but rather:
@Chris Clawson (meloware), I understand that, Those are all related issues, rooting to the fact that we've tried to give fastest core to the main thread. Cycles does special trickery to distribute its threads on all cores. Similar thing can be done for threads on Blender side. But we have no control over threads created by external libraries, like OpenJpeg and OpenEXR. Also, Cycles uses OIIO/OSL which might be creating threads as well, and those we also have no control over.
Wed, Feb 13
Could only do some quick sanity checking, without going too deep into implementation details (not really my area, so might be missing something).
Can we just be removing such code?
Tue, Feb 12
@Brecht Van Lommel (brecht), we used to have, there is prepare_xubuntu_14_10.sh. We also had studio-related distro with silent install which was taking care of everything. But those things becomes out if date very soon, and with heterogenous distro environment such things becomes rather PITA to maintain and nobody does it :(
@Brecht Van Lommel (brecht), for our thread pool it's fairly simple fix. But is a good point about threads summoned by someone else.
Guess half-decent solution would be to not set affinity for main thread, but set it in thread pools (both Blender and Cycles) to:
- Make sure data is localized per node/CPU group
- Allow use of more than 64 threads on Windows
There were few things wrong in dependency graph and instancing code. Should be fixed now. Thanks for the report, closing.
Not sure whether it's really best idea. Thing is, it might be handy for some simple art or references, but SVG might also be used for some CAD things where you don't want any unrequested modifications to the coordinates. We also don't do this for other formats.
Fixed by rB024f5ba2bdb (just made a typo in the Fixes string :()
Fixed by rB024f5ba2bdb.
Think it's fine.
The RNA should indeed be changed though.
@Hossein Shah (hk1ll3r), instead of re-opening old reports, make a new one. With all the information requested there.
Please note that this is not really a place for discussion, but for a bug tracking, where artists report reproducible bugs and developers fix them. For discussions there are other channels like devtalk.blender.org, or blender artists.
Mon, Feb 11
Ok, some discussion dump from IRC.
The patch seems wrong to me. It brings back behavior when eParticleSystemFlag_file_loaded is always stuck on particle system for its every evaluation.
One possible thing which might be needed is that initial evaluation of dependency graph is to be considered as file loaded.
How is this supposed to work on multi-display Linux? I'm doing blender --factory-startup and the window is opened in a way which makes it to stick to the right edge of my left monitor (the window is vertically aligned on center though).
Is the generated output even useful? Do we have anyone using it?
Is this ingroup used for anything useful?
[read it with some amount of sarcasm/irony]
Ok, then i guess here are some final thoughts, to make point clear.
Sun, Feb 10
This is your opinion, for local style changes like this - we can defer to module owners.
Just as we use short names for ARegion *ar, Object *ob, wmWindowManager *wm
This is a change to worse. Was perfectly readable code, converted to a cryptic beast.
Fri, Feb 8
@Dalai Felinto (dfelinto), that or ignore those in the iterator i would guess.
@jm (jarbona), please make a new report following a bug report guidelines and providing all information requested from there.
Re-opening, things are a bit more fragile here, and needs a closer look.
Ok, now i see what's happening.
The physics works in blender units, prior to the unit system is taking place. In fact, the unit system was originally an interface-only thing, and lots of areas are not aware of this.
Attaching file which can be actually used to compare behavior between 2.79 and current 2.8:
Please always attach file which demonstrates the issue.
In my quick experiment rigid body simulation works correct on both 24 and 60 fps. One thing though: changing fps does not invalidate cache, so should be careful there.
term manipulator is no longer in use
Thu, Feb 7
Just so it's mentioned here.
Might be new dependency graph, might be fix in some other area. If the issue is fixed in blender2.8, i'd consider this resolved :)
Wed, Feb 6
@Steffen Dünner (SteffenD), do you mind testing latest build from builder.blender.org?
@Clément Foucault (fclem), "Optimization" or "Speedup" will read more clear and easily.