Sorry for posting another thread related to my black dots render problem, this will be the last (hopefully)…
What I would like to find out is what others do when they come at a point in blender where there seems to be no technical solution for a render problem (black dots and coloured dots), no one you ask knows a satisfying answer and you submitted the problem as a bug, but in the end you just can’t finish your project anyway?
I’ve been in this situation for about three weeks now. What I also did was to try and make changes to my system software and see if this helps, so far it only made things worse: I just upgraded from OS X 10.3.9 (where blender does not work properly for me) to OS X 10.5. But unfortunately there is a major bug in the 2.45 (PPC) version: “Undo” does not work at all on my system… (I checked to make sure that “Global Undo” is on). Now I am trying to get Ubuntu 7.10 installed in a dual boot set up…
So right now I don’t have a copy of blender that works reasonably well on my system.
Even if I can get Ubuntu/blender to work I’ll probably still have this render bug (black dots).
I already thought about changing the content/story of my animation, but just don’t see how I can replace that halo spot (that seems to be part of the problem) without loosing too much on the visual side of things.
I also thought about just starting with my next project but realised that I can’t - there was always one thing that kept me sticking to blender even when I had multiple problems to deal with: I soon had learned that I could trust blender, that if something did not work it was because I did not know something yet, not because it was a bug.
But this whole episode with the black dots and that FFMpeg (?) bug have changed things for me and realise I have lost quite a bit of faith in blender, it seems not infallible anymore as I once (naively?) thought.
But what to do…? Start looking at commercial software? (I recently took part in an 8 week long 3ds Max training and still can’t believe that this is what most people seem to use…!) Wait until blender 2.50 comes out in Spring? Invest in new hardware/software where blender works?
What does the 3D geek do when his/her favourite (open-source) app just does not perform the way it used to - when you just can’t render your animation…?
This new thread reads as more of a “I wanna bitch about my problems” thread then an attempt to ask for help, but I’ll give it a try anyway.
After a quick run through of your other threads, it looks like the real issue is with the results you get from the encoding process. In other words this is NOT a “rendering” problem (See your thread title) it is an “encoding” problem. BIG DIFFERENCE!
It also looks like you have been given excellent advice on how to approach your issues, but there is very little evidence that you have applied it.
So…
Are you rendering to a lossless sequence as Mpan suggested? (png, tga)
And if so are you getting artifacts in those sequences?
And if so, have you tried Malifico’s advice and used the “fix” node in PlumiBlender?
If your not yet rendering to a png, tga or exr sequence, your just wasting time.
If you are, then the PlumiBlender “fix” node (with exr) should solve your problem. (at the sequence level)
Once you have a clean sequence, you have MANY options on encoding, (codec and tool to encode with) but each of the encoding options are going to have their positives and negatives regardless of what tool you use to process the result, so don’t go blaming the tool
The issues with h264 have been pointed out, so if thats not a viable process you will need to use something else. Choosing the proper codec and setting the correct values for that codec is a whole matter in itself. Your post that “it worked fine with other video” is meaningless.
If I have this ALL WRONG, then what you need to do is post a test Blend for us to look at.
I was just told to check the settings for the halo lamp that I use, I’m still trying to understand the details here, but possibly this is causing the black and coloured dots that I get in my renders…
To your question:
I use Targa Raw (640x480) (but the errors just become more visible in 1280x960).
So far I could not get PlumiBlender to work, the OS X build crashes on start on my system (I left my log-file for the builder), but I’ll try the Ubuntu one as soon as I have Ubuntu installed…
So thanks again and I’ll post more about the render/pixel problem that might be caused by the settings for the halo lamp as soon as I fully understand what is going on.
Please see the sample .blend I attached in my bug report. (And I only reported it as a bug after discussing it in the forum - believe me - I really tried to make sure this is worth bothering others with…)
I get 1 black pixel from a test frame in your Blend using latest SVN Blender. If you are doing your output to a web codec, the chances are these will never be noticed once this is encoded. The encoding process itself will most likely remove such small errors.
Or, as has been mentioned before, render oversize and then scale down the result. Single pixel errors will be discarded in the process.
If you need HD quality, just do what Hollywood does and touch up the bad frames. Production work is about getting the job done, not perfection, and that’s true no matter what software you use.
Unfortunately not, this is also what I first thought. But when encoded with H.264 at a higher kbps rate the errors become visible and look like dirt/scratches on celluloid film.
When I render at a higher resolution I get more errors, I think I did a test (with going back from 1280 x 960 to 640 x 480) and as far as I remember this did no solve the problem for me.
I started out with hand painting over the pixel errors using the Gimp, but once I reached the part where I use toon edges I saw that there were too many of those errors to keep working like this. Basically all in all I’d have to analyse about 2000+ single frames and need to identify those 100 (or 200+ ?) that are affected. On those I have between 1 or 5 (?) pixel errors that need to be hand painted.
If this is just how it needs to be done, I’ll do it of course! Only until now I’ve never seen anything like this in any of my blender projects. So I was concerned, maybe you can understand…?
The problem here is identifying the frames with the pixel errors: on the one hand they are hard to see when you look at single frames, on the other hand you do see them in the animation as either black dots that just come up once in a while really quickly or as scratches/dirt (and also once converted to H.264)…
I might still be fine with this 4 minute animation with painting over the pixel errors, but I am already thinking of what I should do on more ambitious projects where I’d have to look closely at many thousands of frames… I don’t think this is how it should be, so this is why I also want to understand what exactly is causing these errors and how it can be avoided.
So I now assume that my settings for the halo lamp need to be adjusted - at least I’ll try to find settings that don’t produce any pixel errors.
Edit: I added a 50% scale node to the end of your node chain. Rendered at 1280*960 - NO ARTIFACTS - but I don’t know which is the best frame to test this on.
If you look at “Example 2 (toon)” (Scene selection from .blend file) move the camera 1000 BU on the y axis towards the 3D objects and render this image. You should see a longer, thin line in the upper/middle part of the image. This is what will look like a scratched film later and is a bit hard to paint over, but it can be done of course.
I also attached my test render with these scratches (only converted from .tga to .jpg so that I can upload it to the forum).
The problem with the solution you offered is that it seems that it sometimes works, sometimes it just does not. I also tried many other things (like changing the objects in the second render layer) and first thought this solves the problem - only to see that these dots then appear in other places. Yes, for individual errors this might be the solution, but once you have a couple of hundreds frames with errors the whole process of identifying those frames, rendering them in other resolutions or hand paining over them seems not like the solution I should aim for to me.
H.264: simply because up to now it is the best codec I know of, it is industry standard and should be able to compress anything in any kind of quality - of course you have to know how-to do it, and so far for non 3D video works I am very happy with it.
I uploaded your scaled/cropped version and marked the pixel errors it has - maybe this shows how hard to see those errors are, but believe me, they do show up in the final animation…
Now imagine you do this with a couple of hundreds of frames only to find out that it does not really solve the problem (while others keep insisting that you should just render them at another size…)!
There is a problem, it might be due to the settings of the halo lamp, but for an animation with 4900 frames I don’t think I should try to just render frames with pixel errors again without trying to understand why it happens in the first place!
What would you use?
For this animation… I don’t know, I’ve delivered for my clients in every thing from Quicktime Sorenson to WMV, in all kinds of codecs. This is not the place to find the right codec for this type of content.
H.264: simply because up to now it is the best codec I know of, it is industry standard
I KNOW that the issues h264 has with content like this have been pointed out to you, but you still insist on trying to force it to do something that’s NOT WORKING. I could care less if it’s a standard - it means NOTHING!
I would be making tests with other codecs/wrappers to find one that did work. The errors you are showing me are SO small that I can’t believe they would be a problem with the correct codec/wrapper combo (web delivered) Perhaps encode to AVI JPG at 80% quality to “smooth” out the spots, and then re encode that.
At this point I feel you are just doing a technical exercise. Hopefully the halo lamp changes will get you where you want to go.
no dots here. possibly hardware bug. renders ok on intel pc.
When I have a problem that I cannot solve, I just start eliminating/simplifying until the issue goes away.
I’ve gotten lines on renders when the camera is perfect right angle to a plane etc, jiggling the camera makes the lines go away. I assume they are divide by 0 or rounding error problems. A regular patter of dots sounds like a cumulative rounding error to me.
Possible workaround for now. Put your halo light on another render layer and blur it 2-3 pixels before combining it with the other layers. I did some tests that looked to work well on the “black dot” problem.
This is interesting… I have a lot of shots where the camera is placed in a perfect right angle etc. to objects/a light or moves exactly through it’s centre. In some of those instances I get these errors (and in others not…). So I’ll also try to make some adjustments here so that it still looks symmetrical/in a perfect right angle (I need that for the visual style) but is in fact slightly off from it…
Ok, that’s a good idea and also sounds like a practical way of fixing similar errors in other instances where there seems to be no real explanation - now that I know that the halo lamp is what I need to watch out for it should be easier to work around this.
If I find any other workarounds worth mentioning I’ll post them of course to this thread - I have a feeling that sooner or later someone else will be in a similar situation - subtle errors like these can drive you nuts, they are hard to point out to others, hard to see when doing tests, but somehow show up in the final product just when you think you are almost done…
