Huum, theres absolutely no reason that 2x gpu who are purely identical outside the distributor brand ( Sapphire and Gigabyte ) will act differently. untill one have an hardware problem.
Both have the same core, same features… Even if the ram was different ( lets say hynix and Samsung )… there will not be any difference in term of render. Normally even the video output quality should not differ… ( in term of color, or anything ).
That’s what i thought, but it’s still what happened. It may be that since the Bloom effect is always flickering and changing size that the rendered result will vary depending on when you press the render button. I’ve also had some materials show up differently on the archviz scene (attached) and i originally thought it was the hardware until i rendered it again and that time it showed up fine. The material probably failed to compile.
Hopefully not, as AMD’s drivers are opensource now compared to 2011.
If you have set anti-aliasing to 16 times then it would be more consistent. At least on my tests when it worked.
I don’t see such an option anywhere, are you referring to the viewport multisampling setting in User Preferences? Because that doesn’t make any difference…
In the top menu:
Render -> OpenGL render Options -> Anti Aliasing Sample -> 16
Ok that helps. I expected those options to be in the Render panel on the right, like they were for Blender Internal… Now comparing it to the old renders, the bloom is almost the same amount. I noticed that the old Sapphire render had a glitch where it would light the vertical lines of the lamps for some reason. I also noticed that the flickering might be related to the overlay engine - the bloom gets overexposed every time you hover over the manipulator or a light.
intel GPU does not work with Eevee either!
That’s because it’s not a real GPU…
There’s always gotta be a troll.
If you don’t agree with this post existing, don’t read it.
There is no such list because it would be a waste of time. There would have too much things to put in that list.
Devs published roadmaps that are approximations and only reevaluated, updated after few months.
https://wiki.blender.org/index.php/Dev:2.8/Source/Depsgraph/Planning-October2017
https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/Eevee/Roadmap-SeptDec-2017
There are posing basis about 2.8 and trying to fix bugs for a 2.79a at same time.
So, they don’t have much time to waste on communication about 2.8 features that are not working.
It is also the reason why bugtracker is closed about 2.8.
It is too easy to encounter something that does not work well in 2.8 to make a useful remark about that which does not imply a “Yes! I know.” reply from a dev.
The only thing meaningful that we can do is to comment their last work closer to when it is commited.
Sorry you lost me there, how is he trolling?
Ok trolls and non-trolls let’s keep this thread useful for those who want to dive into eeVee yeah?
we all know it is alpha beta gama six not ready for production
still it is fun for those who want to explore it to do so
Cool? Awesome!
Two questions
To simulate portals it is best advised to place area lights into each window again?
I struggle a little to fully understand what to expect from the irradiance volume
any suggestions about setting tips?
how can you get those artifacts away
for a room that is not like a cube what is the best strategy to use the irradiance volume?
add two more ?
should the model fit into the inner irradiance volume box?
to my understanding no object should overlap with one of the volume spheres right?
^
I also would like to know the best practices of using the irradiance volume… like is it better to add several default resolution boxes (4,4,4) or one huge one with a high resolution ?
I know the Video - i am looking for more in-depth explanation for why things work in a certain way
Possibly the problems in opengl and lighting generate some strange things.The lightprobe move generates weird things considered that the problem comes from the use of opengl 3.3 that is what I felt. If the lighting is relatively strong lightprobe can generate strange symbols.
Solution: Climb the subdivisions of the light probe, then upload the samples, i use at least 64 128 and, if possible, and finally all the maps (shadow maps and other) minimum at 4096
I’m not ruling out hardware failure, but if you have either faulty application code and/or driver code and you enter the realm of undefined behavior, even subtle differences in hardware/clocks can make a visible difference in a render.
The “fun” thing about OpenGL is that it’s pretty easy to get things wrong, that issues are more likely to show up only at runtime, on the many drivers (of varying quality) on different operating systems.
For best results, I suggest to get the exact GPU that the main developer is working with most of the time. If the developer is using an NVIDIA card, absolutely get an NVIDIA card, because NVIDIA drivers are more lenient.
I know that Eevee is still alpha, but the effort to fix every problem for everyone is so high, it’s just not going to happen.
Hey guys, It seems that the latest builds show this problem: It renders animation perfectly in Open GL animation, but not in the regular CtrlF12 animation. In this one, just render the same frame always.
The problem is that in Open GL animation we cannot achieve the same clean image as in the regular animation using Eevee, which means that in Open GL animation we have to cross fingers to not have flickering edges or noise samples in some reflective surfaces, even using 16x anti aliasing full sampling.
Its easily visible in the comparison attached:
nobody has a tip to clean up those irradiance volume light artifacts on walls?
