EEVEE-Next: Add mesh volume bounds estimation #113731
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#113731
Loading…
Reference in New Issue
No description provided.
Delete Branch "fclem/blender:eevee-next-volume-object-bounds"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This adds correct object bounds estimation.
This works by creating an occupancy texture where one
bit represents one froxel. A geometry pre-pass fill this
occupancy texture and doesn't do any shading. Each bit
set to 0 will not be considered occupied by the object
volume and will discard the material compute shader for
this froxel.
There is 2 method of computing the occupancy map:
froxels center in-front of it. We then convert that
into occupancy bitmask that we apply to the occupancy
texture using
imageAtomicXor
. This is straight forwardand works well for any manifold geometry.
in a list (contained in one array texture). This list
is then processed by a fullscreen pass (see
eevee_occupancy_convert_frag.glsl
) that sorts andconverts all the hits to the occupancy bits. This
emulate Cycles behavior by considering only back-face
hits as exit events and front-face hits as entry events.
The result stores it to the occupancy texture using
bit-wise
OR
operation to compose it with other non-hitlist objects. This also decouple the hit-list evaluation
complexity from the material evaluation shader.
Limitations
Fast
in front of them.
Accurate
in front of them.
Issues to fix
Crossing the surface with the camera near planeFixed by simply reversing the XOR input.make the mesh non-manifold and exhibit the
same issue.
This way missing front geometry fill the space between
the camera and the first surface depth.
Surface crossing camera far plane exhibit issuesFix is to use infinite projection(Caused by above fix).
matrix to never clip.
Non-Manifold object affect other objects. ClipThis is a bit involved andoccupancy bits to the bbox.
might disable some optimization. Consider a limitation
for now.
Object intersections are effectively removedUse layered approach.instead of overlapping.
Volumes objects do not use this prepass makingUse selection surface mesh.them not working at all.
Volume object have multiple boxes in their coarseMight be fixedgeometry. This causes overlapping issues.
by drawing with front-face culling, limiting occupancy
to the cubes volumes and using
atomicOr
instead ofatomicXor
. This would work because cubes are notarbitrary geometry. We might want to do this for
point clouds too. NOTE: This was delayed and for now,
volumes still use their bounding boxes.
Follow ups
in XY dimensions (it does in Z). Needs to be fixed as
part of changing the sampling scheme.
Examples
Fast
Accurate
EEVEE-Next: Add object bounds estimationto EEVEE-Next: Add mesh volume bounds estimationEEVEE-Next: Add mesh volume bounds estimationto WIP: EEVEE-Next: Add mesh volume bounds estimationWIP: EEVEE-Next: Add mesh volume bounds estimationto EEVEE-Next: Add mesh volume bounds estimation@blender-bot build
I have not checked the occupancy shaders yet, but I miss some kind of overview of how they work.
(Edit: Just saw the PR explanation. I would add that to a comment)
Unless you think they could be useful for something else I would rename the files prefix to 'volume_occupancy`.
Note that with this patch applied Volume lighting is broken. And volumes don't seem to render at all in main. 😢
It's seemingly a recent regression.
Build from October 12 vs this PR:
@ -295,13 +313,18 @@ Material &MaterialModule::material_sync(Object *ob,
mat.planar_probe_shading = material_pass_get(
ob, blender_mat, MAT_PIPE_DEFERRED, geometry_type, MAT_PROBE_PLANAR);
}
}
This enables volumes for baking instances. Is that intended?
It makes sense for sphere and planar probes, which didn't exist when this code was written, but I think it still makes sense to disable them for volume probes.
That wasn't intended, but that's on the roadmap :D. I'll revert for now.
@ -45,1 +47,4 @@
MAT_GEOM_GPENCIL,
MAT_GEOM_VOLUME,
/* These maps to special vertex shader. */
MAT_GEOM_VOLUME_WORLD
is a compute shader.The goal would be to port them as vertex shader so that we could shift some computation of the material towards the vertex shader. But that's something still in design so I'll just replace it with "special shader".
@ -768,1 +831,3 @@
inst_.sampling.bind_resources(volume_ps_);
enabled_ = false;
for (auto &layer : layers_) {
(*layer).sync();
Why do this instead of
layer->sync()
?@ -769,0 +841,4 @@
for (auto &layer : layers_) {
/* TODO(fclem): We might want to skip empty layers as the clear overhead is be significant. */
/* TODO(fclem): Move this clear inside the render pass. */
occupancy_tx.clear(uint4(0u));
Remainder that we saw that this kind of texture clears without a framebuffer was quite slower. Probably not something we should address in this PR, though.
Yes, but that's quite an ambiguous position. This texture is not part of any framebuffer. So we need to manually clear it.
@ -542,33 +644,29 @@ class PipelineModule {
case MAT_PIPE_DEFERRED_PREPASS:
return deferred.prepass_add(blender_mat, gpumat, false);
case MAT_PIPE_FORWARD_PREPASS:
if (GPU_material_flag_get(gpumat, GPU_MATFLAG_TRANSPARENT)) {
I don't get the removals from this file. Do they belong to this PR?
Kind of. They are related to the way the transparent material gets added to the pipeline which is similar to the volume one. This function shouldn't add any transparent object.
@ -278,0 +280,4 @@
GridAABB(int3 min_, int3 max_) : min(min_), max(max_){};
/** Returns the intersection between this AABB and the \a other AABB. */
GridAABB intersect(const GridAABB &other) const
I think
intersection
would make more sense.@ -441,0 +444,4 @@
MAT_GEOM_VOLUME_WORLD,
MAT_GEOM_VOLUME_OBJECT,
MAT_GEOM_VOLUME,
MAT_GEOM_VOLUME);
Repeated.
@ -154,3 +156,3 @@
GPUMaterial *gpu_material = material_array.gpu_materials[i];
if (material.volume.gpumat && i == 0) {
geometry_call(material.volume_occupancy.sub_pass, geom, res_handle);
Shouldn't this be done only if the material has a volume output?
If the material has no volume, the shading group will be
nullptr
and this call will be a noop.@ -315,0 +333,4 @@
/* Use bounding box tag empty spaces. */
GPUBatch *geom = DRW_cache_cube_get();
geometry_call(material.volume_occupancy.sub_pass, geom, res_handle);
Why do regular Volume objects need an occupancy pass?
Because the material compute shader is dispatched on the BBox converted to the froxel grid AABB. This inflates the bounds quite a bit in any case. So using the occupancy map this makes sure to trim the excess. Also this will help further optimization.
I think we could reuse them for object thickness. Nothing makes them specific to volume except their current usage.
If that doesn't break
main
more than it currently is, I would propose to commit this as it is to unlock the other material pipeline refactors that needs to come after it. We can then fix the remaining issues with volumes inmain
.@blender-bot build