Blender core developer, working at Blender HQ.
- User Since
- Sep 12 2004, 3:45 PM (795 w, 2 d)
Please provide an example blend file that makes this easier to debug. With a round mesh it's very hard to see whether the wheel rotates. There are also nodes in the material that don't seem to be used. All such things take time for developers to investigate.
I'm removing the Animation tag as it doesn't seem to be related to the animation system.
I'm reassigning this to the Nodes & Physics project, as it's related to the Soft Body simulation. When I turn that off, things work properly.
One thing I don't understand from a conceptual point of view, is why there are start and end parameters. Why not convert all the baked data there is?
As the code was moved from a place that already had those start and end parameters, keeping them around makes sense, of course. When it comes to the new un-bake operator, do you have any strong feelings about the default values ? Would it work to have them initialised to INT_MIN and INT_MAX so that all baked data is converted?
Sat, Dec 7
Fri, Dec 6
I can also reproduce the issue in just the viewport. Go to frame 101, press Space to play, press Esc to stop playback around frame 120. This goes back to frame 101, where the curve has an offset from the bone it's attached to. I gave the curve some thickness to make it more visible:
I can confirm. The bouncy ball should go between the red lines, and then through the red circle. It does so in a viewport render, but not in a render render.
Please attach a blend file that allows us to quickly reproduce the issue.
The same happens (also in make_object_duplilist_real()) for constraints, they also disappear.
IMO the current approach that only visible objects can be selected is a sane one; this prevents a whole range of issues where people are performing changes to objects without knowing about those changes, because they wouldn't see all selected objects. In this particular case it backfires, though.
I can't quickly solve this, don't see anything obvious exploding in the code.
Hi @Christian Brinkmann (poor), thanks for the pointer.
Thanks for getting back so quickly :)
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.
I'm moving this task from the 'Planned/Scheduled' to the 'Needs Further Planning' workboard, as there is no plan or schedule.
I'm moving this task from the 'Planned/Scheduled' to the 'Postponed' workboard, since there is no plan/schedule, and it's been idle for almost three years.
I'm moving this task from the 'Fixes in Progress' to the 'Postponed' workboard, as there is no fix in progress at the moment, and the task has been idle for five years.
With Actions being stashed automatically on an NLA track when you switch actions on an armature, is this still such a big issue as it was at the moment of writing?
There is no concrete plan/schedule here, so I'm moving this task to the 'Postponed' workboard in favour of the more recent proposal in T68962: Graph Editor: Link Visible and Selected states.
Note that this is rather similar to T68962.
Moving this to the workboard 'Postponed', as it doesn't have any actual plan/schedule and has been sitting still for two years.
The problem is that the code is normalising a vector without checking whether this is actually possible, and that it doesn't have any sensible fallback in that case.
Marking this task as To Do, as it's a known limitation of Blender and not a bug.
Disabling normal export and re-exporting from 2.82 halves the file size
Thu, Dec 5
- USD: Support '.usd' as export extension (thanks @superfunc) and proper filtering in the file browser
- USD: Fixed export of animated meshes + using sparse value writer
I wish that "intuitive behaviour" meant that it was also implemented. Unfortunately that's not the reality.
I can't semi-confirm. I took your blend file, applied both Subdivision Surface modifiers to be 100% sure it uses a large number of vertices, and produced a 5.6 GB Alembic file. Playing back this file is done at approximately 3.2 FPS in 2.79, and at at approximately 1.9 FPS in master. So yes, it's slower, but not 4-5x slower.
This is caused by the interpolation of vertex positions between frames. This interpolation causes smooth transitions from one shape to another, and is important when slowing down things like animated characters. When vertices are added or removed, this interpolation is no longer possible. After all, you can't have half a vertex in between the two frames. The Alembic importer tries to detect such situations, but as you see, this can fail. What's happening is that between frames 8 and 9 some vertices change wildly in their position, swapping places between the front and the rear of the sphere. However, the number of vertices, edges, and faces stays the same, so the reader thinks it can interpolate, causing the observed behaviour. Detecting such changes is hard to do, because even a large change from one frame to another could still be valid, and it would also have a performance cost.
I've marked the task as a 'To Do', because it doesn't appear to be a bug. If I drew the wrong conclusions, please let me know.
@Darryl F Neal (dfneal38) with "the in-betweens function", I'm assuming you mean "Push Pose from Rest Pose" and "Relax Pose to Rest Pose". The behaviour of these can be found in the pose_slide_rest_pose_apply() function, which shows that this isn't implemented for bendy bones yet. As such, it's not a bug, but simply a missing feature.
- Updated after more feedback from @William Reynish (billreynish)
@Bastien Montagne (mont29) Could this be due to a bug in the library overrides system? The fact that it creates a new copy of a brush when creating a new scene, and after that things get corrupted, made @Julian Eisel (Severin) and me think it might have something to do with that.
I did some digging, and I suspect it's due to the tool system or the brushes. The crash happens in BKE_main_override_library_operations_create(), which iterates over all ID datablocks in G.main. This causes a segmentation fault when iterating over the brush datablocks. Here are all the datablock pointers (so id), their name pointer (id->name) and the contents of that name.
Wed, Dec 4
It's all the same crash, and easy enough to reproduce, so I don't see the need to update the description, thanks.
- Updated descriptions with texts from @William Reynish (billreynish)
Deform the mesh or curve using an external transform cache in Alembic format
LGTM after the comment change.
Thanks for the vote of confidence, I appreciate it. I don't mind nitpicking now, though, so that once it's in master it's good to go and we don't have to look at it again.
Tue, Dec 3
Where is the broader design? This is something that's now being copied from one constraint to others, which to me indicates that there is a fundamental limitation of the constraint system. We should not keep copying workarounds for that limitation, but rather come up with a proper solution.
@Richard Antalik (ISS) do you want to fix this? If so, please assign to yourself. Otherwise I'll take a stab at it.
Ok, the fix works, but it's still confusing. The patch description doesn't mention anything about the interpolation type changing, and neither do the tooltips. Would it be better if linearly interpolated keyframes are changed back to linear after the decimation is done?
I find the diff title & description a bit vague. What does "Lock-Relative mode" mean? All the way at the bottom of the patch I think the RNA tooltip is clearer than the patch description itself.