whos notifying who here? a couple crash confirmations really bothers you?
yes i confirm too, its crashing. then what?
take your little tiff somewhere else, and stop tracking this thread if you dont want to hear about other peoples feedback
whos notifying who here? a couple crash confirmations really bothers you?
yes i confirm too, its crashing. then what?
take your little tiff somewhere else, and stop tracking this thread if you dont want to hear about other peoples feedback
https://wiki.blender.org/wiki/Communication/CodeOfConduct
first and final warning for this thread
So is it appropriate and on-topic to share crash confirmations here or should that be done on the bugtracker? Thatâs the topic being discussed and the Code of Conduct doesnât really clarify anything there
Feedback threads are somewhat flexible, itâs whatever the specific module wants to accept, not my call to make, overall moderation wise however i will try to swiftly put an end poor behaviour when things get a little bit too personal.
Whether they worked for pay or for free, I suspect a heck of a lot more people have worked on those game engines compared to eevee. As far as I know both eevee and eevee-next are herculean efforts by practically a single person with occassional minor help from a few other people and sometimes apple employees will show up to make sure it works faster on apple hardware. Am I wrong?
@thinsoldier I think youâre not wrong
I remember Eevee origins like this:
Clement Foucault was sharing, at Blenderartists, his WIP work on a⌠separated branch of Blender that allowed it to display PBR textures.
Hereâs the link:
Blender PBR viewport Branch
This caught everyone attention (including me that was praying for this since 2009) and eventually gain so much traction that green lighted Eevee and Clement worked mostly, if not completely, alone on it.
This is how I saw it as spectator, donât make a clue if itâs factual
But letâs talk about Armory game engine, because it also was pretty much ignited by a single person. Today is open source and is being developed by a team of volunteers, but back in the day was one person alone and in comparison with Eevee, the graphics were faster and featured more recent methods⌠If I recall correctly, Armory featured real time global illumination even before Unreal.
After the post, that you quote, Iâve been thinking (again)⌠and this is actually the key of all this⌠it feature more recent methods because it uses modern versions of the OpenGL api Because Blender needs to be compatible with older machines and be robust, Eevee was limited to OpenGL 3.3 (I think) while Armory and GoDot were already taking advantage of OpenGL 4.xx. These days, at least GoDot, is even on VulkanâŚ
Anyway, Iâve seen some more names contributing to EEVEE-next, but they sure feel that can be counted by the fingers of a single hand
I personally prefer rasterization more, its more crisp and texture detail is better, its more logical to use rasterization as a base and add raytraced features that can make us have both worlds, rasterization is not always slow, it depends on vulkan Vs opengl etc. that make impact on handling polygons and how advanced the code is in terms of optiimizations and especially grass or vegetation culling , many game engines handle many big scenes even without lods better than blender if only vegetative elements are added culling by cam or distance.
Texture detail should be the same between a rasterized and ray traced renderer as the texture detail is determined by the texture, not the renderer. As for rasterization being âmore crispâ over all, it depends what you define as âcrispâ and what render settings you use in the respective render engines.
Rasterization isnât slow. And just like any piece of software, part of itâs performance is based on optimizations. Itâs just that some of the techniques that many rasterization render engines use do not scale up to scenes of high complexity as well as ray tracing does. For example, if a rasterization render engine uses shadow maps for shadow rendering, and you want high quality shadows from many lights, then using ray tracing may be faster for the same or better quality.
I have downloaded the latest 4.1 build and going to EEVEE and not EEVEE Legacy doesnt seem to work with light shadows?
In fact I cant seem to get any raytracing to work, I have a RTX 3090.
I really would like to try out EEVEE-Next but every build I tested keeps crashing on 3 different computers when changing the viewport to viewport shading. I have tried the last 10 builds with a 3090 / AMD CPU combo and at least 3 of the latest builds on 2 other machines with NVIDIA / Intel combos.
Seems like Iâm not the only one with this problem but I havenât found a solution anywhere.
TESTED VERSION: blender-4.1.0-alpha+main.a39c16270ce5-windows.amd64-release
Todayâs release, after many crashes in the releases of the previous days, is working for me.
Only good news today:
A rather complex shader setup using the ShaderToRGB node is giving very similar results in both EEVEE and Legacy. Some lighting discrepancies, but those may be due to some changed setting deep in the new version. Will keep looking
The previous problem with the world shader not respecting the Light Path node seems to be resolved.
EEVEE LEGACY
EEVEE
@Jeroen-Bakker @fclem @brecht you might find this interesting:
Screen Space Indirect Lighting with Visibility Bitmask
Screen Space Horizon Global Illumination (Shadertoy Implementation)
And
This build from this morning:
blender-4.1.0-alpha+main.a39c16270ce5-windows.amd64-release
Is again working for me without those insta-crashes weâve had for the past few days - Windows 10, 3060ti.
It doesnât crash for me, indeed, but EEVEE Next lights arenât working (no lights/shadows). Anyone else having this, too? Just to make sure itâs not faulty on my part
Lights (point and sun) are working for me, as well as shadows.
Confirm. Lights arenât working in blender-4.1.0-alpha+main.a39c16270ce5-windows.amd64-release
not sure if this has been mentioned already, but since a few days I get absolutely weird results in specular channels, i.e. no specular AT ALL. See the two previews down there, where I crank up the IOR level to ridiculous values, having no effect at all, and after just adding 1% to the value, I get full specular at 100% level.
In the two screenshots I have set the viewport preview channel to specular, so no other contribution gets in the way. Anyone else seeing this? Eevee Legacy does not show that behavior.
same problem â #116900 - EEVEE: Light spot is very dim - blender - Blender Projects
Shadows are not anti-aliasing, and it seems to be determined by the relative angle of the surface vs the light/shadow direction. On the floor, theyâre quite smooth, but on the curved surfaces and side of the cube, they are not.
This happens with both a basic PrinBSDF, and a diffuse/shaderRGB shader (so, problem doesnât appear to be specific to one shader.)