I am getting a color fringe on the emission object if the DOF is on. Is it expected behavior?
It goes away if I enable Jitter Camera in the DOF settings and render the image
I am getting a color fringe on the emission object if the DOF is on. Is it expected behavior?
It goes away if I enable Jitter Camera in the DOF settings and render the image
Not sure if thatâs expected. Please open a report so we can investigate.
Since Eevee NEXT is still a rasterizer, wouldnât it be possible and efficient to render points of point cloud as camera facing quad sprites with a circle opacity mask and spherical normal transformed from tangent to world space?
This way the point clouds would be very cheap to render (just two triangles per point), would look like perfect spheres, and the sprites could be transformed to face the light for the shadow pass, so the shadows would look right as well. Game engine rasterizers do this and it both looks and performs great.
This may be due to my lack of knowledge on EEVEE next. How exactly do you remove the blurriness from the eyes from the below? I would like to make it look like how it does in EEVEE legacy. The plane over the iris has a roughness at 0, transmission at 1. It seems like the farther away from the camera, the more blurry it is. Am I missing anything? I am confused.
Thank you very much for such a prompt response , but I canât achieve the desired effect
.
We need a parameter that removes AO (as it was in the previous version of the engine) and its intensity, but leaves GI (light and reflex). With Max roughness, the entire scene is covered with spots, which are clearly visible on the light interior. The engine performs better under single lamps, but everything related to HDRI performs worse than expected. Night and dark scenes are better, light and bright scenes are worse.
Try playing with the thickness parameters in âFast GIâ . The far thickness has a very high default to avoid energy loss but increases overshadowing. Try setting it to the minimum value.
See the manual for more detailed explainations.
This is a bug in the denoiser.
Please report so we can track it down.
However, I am not sure we will have enough time to fix is for 4.2.
I tried. Its behavior does not satisfy architectural visualization. Try to make a simple room scene with light walls and natural light to understand what the real problems are in architectural visualization. Are there any plans to improve the engine towards more accurate work with the joints of walls, ceilings, floors and interior items?
I will send a video, there are examples of reference rendering of cycle compared to eevee. This is just so that you have an example of how things are today, this is the latest build of Windows, version 4.3.0.
In general, I want to express my gratitude to you for what you are doing, I think many artists will be grateful to you after the completion of this project for many many years to come .
It would be cool if in the eevee settings, in the final version of blender, there were presets for architecture, animation, fast rendering and very high-quality rendering!
EEVEE-Next is still funamentally a rasterized based render engine with many techniques that it uses being deisgned for real time applications. As such it still needs some manual work to try and avoid issues that come from these âfast rasterized techniquesâ. For example:
Iâm sure there are plans to continue to improve EEVEE. Iâm unsure if any are specifically targeted at interior rendering, but Iâm fairly confident that interior rendering will improve as various other improvements to indirectly lit rendering are made.
Sorry, itâs not clear to me. Can you explain what you desire for your architectureal visualization? Is it realistic renders? Nice looking renders? A specific stylized look? Something else?
And whatâs lacking from EEVEE-Next to achieve this? Or what things are performing poorly, thus making it hard to achieve what you want.
I think what she means (and correct me if Iâm wrong) is screen space raytracing doesnât work for archviz. Itâs prone to a series of artifacts that break the illusion of realism like progressive shadow darkening/brightening, illumination from sources outside the frame appearing/disappearing and bounced light appearing/dissapearing. For stills though it works better but for animated sequences it looks fake. Itâs a limitation of SSRaytracing
I would like to make a general plea for Eevee Next: can there please be some setting that allows the ârenderedâ view in 3D viewport be same (as much as possible) as the actual render?
If the general plea isnât clear: I notice that turning on camera jitter for DOF does nothing in the 3D viewport. But it does do camera jitter when I render the image.
I found a bug report where someone asked about this, and the bug was closed (WONTFIX?) because itâs on purpose that the render view is different than the render (?!).
This breaks my workflow. Please let me see in the 3D viewport a preview of what the render will look like. Non-jittered and jittered are very different, and I compose camera angle/position differently between them.
Yes, we are talking about flickering during camera movement or animation. I know that there are these problems even in Unreal Engine, but there they are minimal. So it seems to me there is something to strive for, I think you all perfectly and yourself understand. if there was a setting (slider), which would minimize the impact of AO, it seems to me that this is already to date, was enough for release (this applies to light interiors, which are so popular among clients in the architects).
Unreal, specific software, not for people who want ease and quick results.
Yes, thatâs what Iâm writing about here.
Quick question about Eevee Next updates: Should we expect all NEXT feature improvement updates to land only for version 4.3 and only bug fixes for 4.2? Or will feature improvements updates eventually make their way to 4.2? Should we be testing Eevee Next with 4.3 now to give better feedback? Iâm assuming that the update cycle for 4.2 LTS wonât be on the level of 4.3 Alpha/Beta.
Thanks
Blender 4.2 LTS may only receive bug fixes. Any new feature will land in Blender 4.3 or future version depending on when the feature is finished. At this moment there is no difference between 4.2 and 4.3 as we are all in bug fixing mode.
When new features appear it would be better to already provide feedback during development of the feature. Someone with some knowledge of the development process can then download and provide feedback even before it lands.
Why do I say âknowledge of the development processâ? Features donât appear immediate, the engineering part of it takes time. Often the initial implementation doesnât compare to the final product. But is required to move from the current code-base to the final feature. A good understanding of this allows constructive feedback and reduce the amount of time developers are distracted and need to explain this.
I also believe that such a person would be great to have as part of the Viewport/EEVEE module and help out on a regular basis. I also believe that there are good candidates out there that could help out. A challenge might be that he/she needs to know/understand/learn multiple ways how Blender is used, and that there are multiple options to evaluate.
People can always reach out to the module if they want to be involved more directly via blender chat.
Hi, I donât know if this is a bug or a known issue or expected behavior, but the Thickness input in Material Output is 0 by default, but if I input 0 to it using the value node, I get different results.
should I report this?
https://docs.blender.org/manual/en/4.2/render/eevee/material_settings.html#thickness
If no value is plugged into the output node, a default thickness based on the smallest dimension of the object is computed. If a value is connected it will be used as object space thickness (i.e. scaled by object transform). A value of zero will disable the thickness approximation and treat the object as having only one interface.
Thanks for the reply. I forgot to look through the manual, sorry.
Just my opinion, but I think it would be better to display just âFloatâ instead of â0(Float)â when hovering the mouse over the socket. I was confused on this point.
For example, the Vector Input socket of the Image Texture Node says âVectorâ instead of â(0,0,0)(Vector)â.
I think seeing the value is very useful though.
In the texture node, the vector input isnât a collapsed socket, it has clear, always-visible values associated with it, when nothing is plugged in
I agree that it is useful to see the value.
However, the fact that it says â0 (Float)â but actually contains a different value was a source of confusion in my case.
Although, I just notice that this may be off-topic because I found others that were not as intuitive when I looked at other Node sockets (e.g. Normal socket of Principle BSDF).