Followup
| Message |
 |
- Date: 2011-02-09 13:35
- Sender: Janne Karhu
- You didn't attach a blend file, but the first thing that comes to mind is the particle lifetime. If it's still the default 50 frames, then even if the emission stops at frame 50 the particles will be simulated until the last particle dies at frame 100. If this is not the case then please attach a blend file for easy recreation of this problem.
| - Date: 2011-02-11 04:20
- Sender: Jarvis Adams
- The attachment I just uploaded is a simpler (just 1 render layer and less objects) derivative project, this one has been validated by me to give the same issue. I was thinking particles was the problem too, but I made them die after 50. I just now though it might be that when the particle's lifetime is ended, and the time slider hits the end render frame, the physics are just continued for the particles that were created just before that end frame. For example: if particle dies after 50 frames, and end render frame is 50. When the physics baker hits frame 49 and creates particles, the physics baker must continue the physics for those lastly created particles all the way to render frame 99.
In order to personally test that, I increased the life of the particles to 200, and I expected to have a bake time of 200+50=250 end bake time. That was not the case. The bake time remained at 100.
I don't know what's going on with this. I've since made a new project and everything is fine with the new project, but I figured this was worth reporting. There are some other things that I think are buggy with the baking, but I figured I'd just take one at a time on here. Then again, maybe the other problems might lead to why this behavior is occurring. If we call this 100 frame bake, problem 1, then the other related problems are:
Problem 2: when I click in the "smoke cache" subpanel -> "External" button it won't recognize the external cache files that I point it to.
Problem 3.0 (maybe it should be called inconvenience 1): when I uncheck the "External" checkbox, all my bake that was done previously is erased, even though the external location I chose was different from the default that just got baked.
Problem 3.1: If I have a default bake, and just click "External" checkbox, don't do anything, and uncheck the "External" checkbox, it deletes the default cache.
| - Date: 2011-02-11 06:56
- Sender: Jarvis Adams
- Problem 4.0: sometimes, through various projects, cache that was created with alt-A, will be removed, just by left-clicking at an earlier time. I believe this only has happened to me whenever I have High Resolution set to 4 or above.
Problem 4.1: The cache will also be cleared if I press the "Esc" key to stop the "Alt-A" caching. To work around this I have to left-click the "pause" button instead.
I know I'm just being harassing at this point, but these are sincere concerns of mine...
Problem 5: The interrupt of the baking process seems against workflow. If doing a high res, high division, bake and halt the process with any method, I have to wait the full minute or whatever it takes for the next frame to finish baking. I'd really love to be able to halt the baking process, and it just deletes that last cached frame that it is being worked on. That would be way more productive in the workflow of adjusting smoke settings, because normally I'll leave the computer and come back to see baking progress and I might make a decision to halt at that point. The 3d viewer window will have the last frame cached roughly displayed, and that is where I usually decide if I'm going to halt the process or not. If I decide I don't like it or just want some instant render feedback, and I halt caching, I'd like it to immediately halt. Perhaps the caching per frame can be put in a separate process and have an interrupt function that has the ability to kill that process.
Should I put in separate bug reports for these problems?
| - Date: 2011-02-11 16:02
- Sender: Janne Karhu
- Problem 1:
For me only 50 frames are baked in every case, so I feel this is a slight misunderstanding. Apparently you're judging the simulated based on the "number cursor", but this only expresses the completion percentage of the whole baking process regardless of how many frames there are to bake. So the cursor always goes from 0 to 100% even if only the 50 frames in your scene are baked.
Problem 2:
This should now be fixed in r34778, a special case was needed for reading external smoke as it uses the cache a bit differently than other simulations.
Problem 3 & 3.1:
I can't redo these problems. Are you sure that you've actually baked the non-external simulation? Running the simulation with alt-a doesn't yet make the simulation baked (secure from modifications). If you simulate something with alt-a and want to be sure nothing happens to the simulation you should click "Current Cache to Bake" before checking the external cache.
Problem 4 & 4.1:
Most likely these problems are caused by starting the simulation from the middle of a cached simulation with changed settings. Any changes to the simulation settings will make the whole cache outdated and everything after the current frame will be cleared so that new valid stuff can be simulated to the cache. However if the new simulation is not started from the first frame of the simulation then the cache will remain outdated until the caching has been started from the beginning. Pressing esc will return the frame number to the original frame before the playback was started and in the process clear all outdated caches after the original frame.
Problem 5:
Currently the "break baking" test is only done after successfully completed frames. Extending these checks to inside the actual simulation code could be possible, but I'd rather wait for proper baking through the job system (the same one rendering is using). So something like this is most definitely on the todo, but can't really give you a timetable.
And next time yes please use separate reports :)
I'll close this report for now as I don't really see other bugs than number 2. If you still feel some of these are proper bugs then please make separate reports of those with their own test files and explanations.
| - Date: 2011-02-12 08:26
- Sender: Jarvis Adams
- Aaaawwwweeee Maaaaaan! I sooo didn't get the cursor was just a percentage reader. Just last night, I had a moment while looking in the cache directory and found that there were more frames being cached than the icon was displaying. I figured Blender was spitting the cache files or something for some reason. What was even more odd, was I had 300 frames cached, but only reached like 95 on the icon. Oh, this even explains why I thought my computer was running at unpredictable render times. I feel pretty dumb right now. I blame it on sleep. : )
Problem 2: That's great! Having that fix can be my treat if I can get Blender to compile again. : ) I do feel like bug reporting will is going to be where I should start at the moment. I think I can learn a lot from developer's responses like yourself, not just responses to bugs I report, but to other developers with real issues. Later, I might start looking at this issues, try recreating bugs on my machine, read some documentation to help me navigate the code, set some break points, and run Blender in debug mode to understand and possibly solve the issue, and submit a proposed patch.
Problem 3: Hmm, that's a possibility that I used Alt-A and thought I was baking. But I distinctly remember looking at the files being created (the number I chose was 100 frames, so at least I can't blame myself for not catching the Problem 1 distinction there : )), then check marking and immediately unchecking the "External" button, then observing the cache folder again, and seeing the cache had been deleted. I know this, because I made a backup of the cache files beforehand and went through this process at least 3 times. I'm pretty sure I tried many ways ("Bake button, "Bake All", "Current to Cache"... ) in creating the cache too. That's what lead me to find I couldn't use external files as cache. Ah, perhaps there was a project file naming issue. I've recently reported a bug on the image node not accessing files in sequence if the files had a number on the end. Maybe that is related? I'll just submit this as a new bug, but I'll try to recreate the problem just in case before submitting.
Problem 4: Hmm, I was thinking the same thing. This has frustratingly happened to me at least 6 times, I made sure I hit the "Free all bakes" button (repeatedly : P), and put the time slider at frame 0 before pressing Alt-A. I also check the darkened bar to see if bakes remain. At least I think that is an indicator. I try to make sure that bar is gone and I have no effects started presented in the 3d viewer before pressing Alt-A. This issue brings me to another one I've been having, but I'll just submit a new bug report. FIY, sometimes the bar doesn't go away when I press "Free All Bakes". If I can't get this issue resolved, I'll just add "check the cache directory to see that it is cleared" to my other prevention processes, before I do any serious baking from now on.
Problem 5: I've got new understanding of this issue now, but I think the problem remains. It's the cached frame I'm waiting on, it is the percentage change that is associated with the restart of the loop at which Blender checks to see if the user has ended the process. I have no clue of the complexity of the code on this and am glad that you considered it. I'll submit it as a new bug.
I've gotta get going, so it will probably be tomorrow before I can submit any more proposed bugs or reply to anything.
Thank you so much for your attention to these issues. Next time I'll submit separate bugs, I just didn't want to over saturate the list or submit something that wasn't really viewed by you all as a bug. To bad the very first bug I report wasn't really a bug but a misunderstanding on my part : P On the up side, at least I did find one in this first report that is acknowledged.
Before I go, I noticed Blender has a rating system getting started (at least I think its new). I think it is important to management and (personally self-awareness) to have this system. I see you are a "Senior Developer" in Blender Extensions, so it might be too emotional for your peers to rate you, but I still think it is important to get this system started, so maybe I can help jumpstart the system by rating you. I'd like to rate you "dependable" on reliability. Before I do, I'm wondering if rating just one aspect is possible, and can rerating occur at a later time if other areas become known.
| |
|
