- User Since
- Dec 31 2018, 10:30 PM (32 w, 4 d)
At first glance, I see nothing unusual in system-info_imrevarga.txt. I need to spend further time with it, but not right now - I'm off to my job and won't be home again until quite late tonight - 22:00 zulu or so.
It seems that when you set mesh smoothing to flat, the simulation runs properly. (Here, linux/amd card, smooth/flat is irrelevant. The simulation runs correctly in both settings).
That suggests a workaround: First, set mesh smoothing to flat, then bake the simulation - in the cache settings, Particle properties, click on the "Bake" button and let the bake run for the full length of the animation. This is similar to what @Philipp Oeser (lichtwerk) proposed (Delete cache, set smooth off, Bake, test animation in the timeline - new step in bold). I propose that this approach will at least give you a sane cache of the simulation to save and work with and you can move forward with your project. If it does, I'd appreciate a confirmation here. Thanks!
changing settings, clearing cash ... all to no avail
I do not have that issue here. Changing settings clears cache. Baking sucessfully caches a new simulation that shows none of the issues you report. Particulars:
- I temporarily cleared the Dynamic Hair checkbox, which cleared the cache loaded with your file.
- Then, probably unnecessarily, ran the animation with Dynamic Hair unchecked, just to satisfy myself that there were zero frames cached in memory.
- Finally, I restored the Dynamic Hair checkbox and baked all 100 frames. Blender reported a cache of 100 frames, consuming about 25.2 MB
This gave me a clean animation. See T68681.mkv Compare with the animation made with your original file and its original cached data. See T68681_original_cache.mkv
To make these animations, I modified your file slightly: I put a damped track constraint on the camera so that it would follow the head.
Wed, Jul 24
I believe there are already representative reports for this condition.
Hair simulation goes goes haywire...
See T59742 and the associated video.
- Run simulation
If the means to run the simulation is through Cntl-F12 then the simulation will not run correctly. See T62563.
Sat, Jul 20
After spending some time experimenting with this, I am convinced that this report is another manifestation of T54488.
While that report has "mirror modifier" in its title, later work by @omgold (omgold) uncovered broader difficulties with disconnecting/reconnecting hair particles while other modifiers are on the stack, in particular the subdivision modifier, which this poster also included in the stack. See @omgold (omgold) 's commentary there for particulars, along with his emails with @Brecht Van Lommel (brecht). Essentially this is an old 2.7x particle system bug that has carried over to 2.80.
Perhaps there ought to be a "documentation fix" to this and T54488; to wit: avoid (or first apply) modifiers before undertaking hair particle editing sessions, or follow "Noschenko's Rule" and work with "emissions = 0" systems; for reasons that are not entirely clear to me, hair particles originating from particle editing sessions have less difficulty re-finding their root locations after a disconnect/reconnect cycle.
Jul 18 2019
TL;DR - Guide hairs added through the particle editor only are not affected by disruptive translations, scalings or rotations under disconnect/connect cycles. Hair particles emitted by the particle system itself are affected. Set particle emissions to zero and add guide hair only through the particle editor.
Jul 17 2019
@Marek Hollý (asil8567)
Took me awhile to get to my desk last night, but I did run your file and confirm both your original report and the unusual rotations/translations which occur to child hair.
I also could reliably crash blender by test rendering (F12) while in particle edit mode. It does seem your file triggers a "certain fragility."
@George Simister (AnaxondA): If you fixed the problem for yourself, then that is great!
If, in the course of fixing the problem yourself, you migrated away from the circumstances that created the bug - and you can't get back to those circumstances easily in a non-destructive way - then c'est la vie...
Bug fixing mainly depends on a file and procedure that reliably recreates a problem. That establishes the all-important anchor point to start an investigation. In the absence of that, it's mostly time-consuming guesswork that leads to little in the way of profitable results.
This bug report will stay around for awhile in a "Need information..." state. If you happen to rediscover the bug, then post the blend file here and a decent, brief, narrative of how you arrived at the circumstances of the bug. Otherwise, this report will be closed at some point because it offers no useful investigative starting point. Thanks for reporting!
Jul 16 2019
I'm about four hours away from checking this with blender, but this reminds me of T54488. Is there a mirror modifier in play?
How would I upload the .blend file properly?
On the control panel header of the text editor box where you type comments there is a little black cloud icon with a white upward pointing arrow on it - next to the last on the the left hand side.
Click on that; your browser should initiate a file upload session. Click on the browse for file (or some such wording) and navigate to your .blend file and choose it.
You should be good to go.
Thank you for the picture - this helps narrow matters for me.
Could use clarification on 6. "Rendered a quick image to find hair behaving sporadic."
Very well, you are seeing something wrong but the phrasing of step 6. doesn't visualize the issue.
A picture is worth a thousand words, and all that.
Better yet, a .blend file with steps to recreate what you are seeing. Could you post one, please? With steps that lead to this "sporadic" behavior? Thank you!
Insofar as particle behavior being set by vertex groups, this reports shares similarities with T63166, but there is not enough information to declare that one is a duplicate of the other.
Jul 11 2019
Jul 4 2019
The Bspline option does work. There is just a missing tagging, if you click the viewport it works.
@Clément Foucault (fclem) : Yes. That bit me in the posterior regions. I remember going over very carefully relevant parameters and remember looking at Strand Steps, changing it - seeing nothing happen. But, of course, I actually didn't kick the viewport display with a left mouse click. I made a little clip showing that it really does work, as you said - once a deliberate left mouse click was made on the viewport.
So taking everything into account I can't think this is a bug. Or maybe i'm missing something?
You're fine - not missing a thing. On the narrow technical content of this report, you are right: the bug isn't there. I'd vote for closure.
But mouse clicking in the viewport is still a PITA - a UI papercut kind of bug, methinks that's just going to confuse people. Should I open another bug report confined to just that issue?
Thanks for all your great work by the way - you and the rest of the crowd.
Jun 28 2019
Quick bump here. @Sebastian Parborg (zeddb) @Jacques Lucke (JacquesLucke) confirmed, but this bug was never assigned. Not mission critical, but I'd hate to see this fall through the cracks on post-2.80 work planning. Thanks!
Jun 21 2019
A total element count change from 4 to 8 is interesting, for if there is now two radiating points where there were just one before, the isosurface would reflect the resulting change in field strength, which, methinks, we are seeing.
Pity I'm in my office and need to do paywork. Be nice to drop a watchpoint on totelem field and find out where it flips.
Thank you for checking.
Thank you for the uploaded images.
- The first image is an orthographic projection; the remaining ones are perspective. Have you accounted for this?
- Blender 2.80 now automatically switches projections when changing views, which some people find convenient, but this feature can jar the unwary.
- If you go to user preferences and set projections never to change as you shift view, do you still see the problem?
- I apologize that I cannot point out the exact place in preferences to change this setting. I'm in my office and Blender doesn't live here...
Jun 18 2019
Mesh vertex creation mechanisms are in abundance; just not labeled as such. They come part-and-parcel with duplication (Shift-D), extrusion(E) and subdivision. Some single vertex creation steps I commonly use:
- In mesh edit mode - select any existing vertex reasonably close to where the new vertex should be.
2a. Shift-D creates a new - wholly disconnected - vertex. Implicitly, G (grab) has been invoked. Move the wholly disconnected vertex to someplace useful.
2b. E extrudes a new vertex from the selected existing vertex; the two vertices are connected by an edge. Again, G has been implicitly invoked to move the new vertex to someplace useful.
2c. With a pair of selected vertices connected by an edge, right-mouse button menu brings up the subdivision menu. Subdivide once to get a new vertex between the two selected vertices, midway on the connecting edge.
Jun 14 2019
Ah, @Sebastian Parborg (zeddb) ! Welcome back to bug triage.
I disagree (a little bit) with your evaluation. There are Viewport side-by-sides near the end of video clip bugreport_T65565.mkv; Both the 2.79b and 2.80 viewport examples are both cycle-rendered previews and note that the 2.80 children are rendered as essentially first order straight line segments. My impression is that the issue is render-independent and I'm guessing differences in depsgraph evaluation in Viewport/render engine contexts is more pertinent, but I have not done any serious stepping through the code to substantiate that idea. Perhaps this weekend...
Jun 12 2019
I owe you an apology @Juan Gea (juang3d) . As to the "presentation," I was writing allegorically - "tongue-in-cheek" if you will. Sometimes I don't make a good estimate of what comes across in writing. As for your points, I do appreciate them and attribute to them significant basis - thank you for sharing them. To my mind, the tradeoff between ease-of-use and minimum-competence-to-use is one we wrestle with in every interaction between people and systems. As fascinating as this subject may be, however, it is off-topic for this bug report and would be better situated in DevTalk or similar discussion forum. I am looking forward to picking up this thread - or others - with you. Take care!
@Juan Gea (juang3d) . Thank you very much! I get your point that because it can work it does work. That there are parameter settings out there where the whole ensemble just falls into place. Nice bit of work here - thank you again for putting it together and sharing.
Jun 11 2019
Jun 9 2019
These remarks are based on version: 2.80 (sub 74), branch: master, commit date: 2019-06-09 00:10, hash: 8452673a0189. See also gosgood-system-info.txt.
Jun 6 2019
This looks like a duplicate of T58044
Jun 4 2019
May 29 2019
T62563 and @Pavel Rudko (PavelRudko) discussion are related through the lack of persistence of the particle system cache management when a cache is being generated in the context of a Cntl + F12 rendering animation. Rendering depsgraphs are created and destroyed per frame now (since November 2018), so cache management doesn't persist. Ideally, Mr. Rudko's second bullet point furnishes the path to solve T62563, though practically, as Mr. Rudko points out, this proposal is a sketch, not a solution. So I'm putting a flag here for my reference. Noted: that a rewrite of the particle system may very well sweep this problem and its context entirely away, so solving this problem in this specific setting may not have very much long term value.
May 17 2019
I see this too.
May 14 2019
May 6 2019
May 5 2019
I believe this bug is also related to T64175 and T64163. As with the example files of those reports, opening crash_on_undo.blend reveals a session with two open windows; in this case the preferences editor. As with the other two reports, following the poster's instructions, as well as performing any other change (moving, scaling, rotating...), followed by Cntl-Z, causes a crash. The commonality in all three is the second open window.
Seen here as well, following the OP's instructions.
version: 2.80 (sub 60), branch: master, commit date: 2019-05-05 07:44, hash: 1c5860407068, type: Debug
I believe this bug and T64175 have the same root cause.
I have seen this bug here using OP's file (it has been renamed to buggytoy.blend).
Apr 3 2019
Commit: 549468365157 (November 9, 2018) appears to have set the stage for this bug, which is a side effect. Very close to the heart of the matter is the hair dynamics simulation depending on the persistence of the same ParticleSystem object across the initial three frames of animation. With the commit, the prerequisite continuity of ParticleSystems can no longer be guaranteed, as they are reinitialized with the frame-by-frame deletion and recreation of the rendering dependency graph. Currently I'm wandering through the rabbit hutch that is particle_system_update() and friends, looking for either Big Buck Bunny, a contemporary of the code, it seems, or a way for ParticleSystems to be stateless - or at least less stateful. Simpler flavors of simulations, such as hair without dynamics or particle emitters, do not have equivalent dependencies on persisting ParticleSystem objects, and were unaffected by the November commit.
Mar 26 2019
T62893 trips this as well.
I see it here, following poster's instructions.
version: 2.80 (sub 51), branch: master, commit date: 2019-03-23 03:30, hash: 7454fa927b80, type: Debug
build date: 2019-03-23, 07:46:50
- box upon which the backtrace was taken.
Mar 24 2019
Notes based on blender 2.80 commit: 7454fa927b80 Sat Mar 23 14:25:29 2019 +1100 T62563 still persists in this blender version.
Mar 18 2019
In blenkernel/intern/particle.c:psys_cache_paths, a N X (S + 1) array of "hair segment vertices" is built for the N hairs in the particle system, each with S segments. So for four segment hairs, there is a root, tip, and three interior hair vertices, for a total of 5. These "hair vertices" are distinct from model geometry vertices.