Excluded Objects Within a Pass aren't Affected by their Parent's Animation #39995
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#39995
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Windows 7 Nvidia Gtx560
Blender Version
Broken: 2.7a
Just render out the "TROLL_HAIR" embedded scene as an animation, you'll see that although everything is ok, the excluded "TROLL_VUCUT" object is not affected by the animation set on its parent, yet the hair, which is also a child of its parent, is affected resulting in the hair going through the body. The hair is emitted from a separate scalp object. I'd say this one's pretty critical :-/
Exact steps for others to reproduce the error
Render out the "TROLL_HAIR" embedded scene as an animation and check the resulting render output.
Changed status to: 'Open'
Added subscriber: @ajlanaltug
TROLL_05.blend
Added subscribers: @brecht, @ideasman42, @Sergey, @mont29
Hmm… not quite sure about this one, Brecht, Campbell, Sergey, ideas? Is this a desired behavior?
Mm... Dunno... I mean it shouldn't be a desired behavior. no?
This is a tricky topic, we have performances enhancements here that do not update hidden objects, so not quite sure about the real answer, that’s why I ask blenderheads. ;)
I don't understand the description, how would "TROLL_VUCUT" prevent the hair from going through the body if it was not excluded? I don't see any physics simulation, collision detection, force fields or modifiers that would do that in this file?
Are we talking about that kind of thing, or is this about rendering only?
I must admit I do not quite see the issue here as well, since TROLL_VUCUT is not rendered anyway.
But the fact is that, being on a render-excluded layer, TROLL_VUCUT is not updated during the render (it does not rotate with its parent, in the 3DView), but afaik this is desired behavior?
Ah, if the 3D view does not update correctly during animation render, then that's not exactly desired but a bit of a dependency graph limitation at the moment. If the rendered animation is correct, then it doesn't seem like a critical problem though.
Hey there Brecht & mont29;
Unfortunately, the problem is with the the animation not updating correctly during animation render, hence not rendering as it should... I mean, if one scrubs through the timeline, the viewport updates correctly, yet when it comes down to rendering out an animation, the result is definitely wrong. I do hope this finds its way to your recent fix list cuz a lot of objects in the same hierarchy could be excluded from one another in any production, right?
Cheers and thanx for your prompt concern;
AJ
I don't understand the problem then, what do you mean by "hair going through the body"? How is "TROLL_VUCUT" preventing it going through the body?
I just don't know :-/ I have an empty to which the body is parented as well as a dummy scalp object that carries the hair, acting as the emitter object. The body has an SSS shader assigned to it, so I made a linked embedded scene copy of it in which I can render out the hair using CUDA with the body excluded. So far aso good I hope, cuz I don't believe there's anything wrong with this setup.
OK, I'm going through the steps once more:
1- Load the scene TROLL_05.blend
2- Select the Scene "TROLL_HAIR"
3- Set the render Sampling real low, like 30 or 40 so that you can see what's going on as the animation render progresses.
4- Click on "Render Animation" and you'll see that the excluded body (in the passes) stays put while only the scalp and the hair from which is emitted are affected by the rotation of their master empty.
5- Scrub the timeline and you'll see that everything looks OK in the viewport. Render out a single frame, and you'll see that the expected is rendered which is the scalp, along with its hair and its sibling, the body transforming in accordance with their master empty...
Ok, I must be missing something obvious, but I still don't understand "you'll see that the excluded body (in the passes) stays put".
Where do you see this, there is no render layer in this "TROLL_HAIR" scene that includes the body? It renders one layer, and the body is excluded from that layer. So where do you see that the body stays put? I'm not sure what "in the passes" means.
@ajlanaltug, what we do not understand is, why that non-rotating body is an issue for you, since it is not rendered?
Dear Mont29;
A picture is worth a thousand words;
1- Render out an animation out of "TROLL_BODY" at a low sampling level.
2- Render out an animation out of "TROLL_HAIR" in its current state, again at a really low sampling level.
3- Comp the HAIR pass on top the BODY pass and you'll see my point.
The reason I went through such a setup was to be able render the hair, background and wireframe passes out using GPU, cuz SSS is currently not supported in GPU (hoping it'll be tho)
If you followed the steps above, you'll see that each sub-scene represents a separate pass, the setup of which is not possible in a single one (different render engines and/or devices for individual passes) and that this is not a bug that can't be just disregarded easily...
Ok, but that's not going to work with the setup you made. You have hair over the body over hair again, and you can't combine that correctly with this render layer setup. If you add one on top of the other then either part of the hair or the body will be occluded wrong.
I think there's two ways you can do such combinations correctly:
With the second approach you could exclude the other object entirely, though you will be missing shadows and other light interactions. And generally the second approach gives quite poor antialiasing and doesn't work with transparency.
Dearest Brecht;
I'll definitely give your advice a go, that's for sure... But, with all due respect, I must insist that my setup works dead on. The body receives shadows cast from the hair, that's one pass. The hair has the body excluded, so when you comp the hair pass on top the body, the fit is snug :) To prove my point, I'm including a quicktime of my final comp (Please forgive the poor quality, the server seems to have strict quota rules) I rendered this one out using a manual override assigning a holdout shader to the body instead of excluding it in the hair pass, technically they both yield identical results, except that the one that I initially sent you behaves weird. But, nevertheless, there's definitely something there bug wise, right?
Cheers;
AJ
TROLL_01.mp4
Ok, I've been playing around with the scene and seem to have found something out. I've seen that many people, including Kent Trammell have the hair emitted from a dummy surface due to many reasons, on top of which is the one that coincides with mine, to comp them with the main surface or whatnot. Because in Blender's hair system, the hair is not a separate object tat can be treated accordingly in a pass, the emitter and the hair become one. Hence the reason why I unchecked the "Emitter: option under the render tab of the hair attributes. When I checked that option, the body started rendering in accordance to its parent's animation. But the weirdest thing is that the body has nothing to do with the hair, the hair is being emitted from the dummy scalp object... I really don't wanna be a nuisance, but if I'm not missing something, there's definitely something there me thinks :-B
Cheers;
AJ
I've been a pain in the tuchas enough already, so here's small update; I can see your point clearly now about the exclusion thing. It seems that I should have had only masking turned on for the body, the exclusion does away with the body reacting to its parent's animation. I dunno if this is normal but at least I seem to have had the problem stemmed out. Thanx a million to everyone for being so very attentive, patient and helpful.
Cheers;
AJ
@brecht, i'm not sure after all, is there something to be fixed?
Changed status from 'Open' to: 'Resolved'
Actually there seems to be be no bug here, so closing.