Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Support getting hit vertex positions when raytracing. #362

Open
Vecvec opened this issue Jan 7, 2025 · 7 comments
Open
Labels
enhancement New feature or request

Comments

@Vecvec
Copy link

Vecvec commented Jan 7, 2025

Is your feature request related to a problem? Please describe.
When ray-tracing the vertex positions of the hit triangle are almost always useful (e.g for getting the normal). Obtaining vertex positions currently requires binding extra resources to the shader even though acceleration structures should have this stored in them (technically an acceleration structure does not have a layout, but there doesn't seem to be a way to avoid storing the positions)

Describe the solution you'd like
HLSL to support something like Vulkan's OpRayQueryGetIntersectionTriangleVertexPositionsKHR/HitTriangleVertexPositionsKHR

Describe alternatives you've considered
Just getting this from the vertex buffer - unoptimal as previously described.

Additional context
I'm quite new to HLSL, so have I missed some way already in HLSL that can do this better than binding an index and vertex buffer?
Vulkan proposal: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/proposals/VK_KHR_ray_tracing_position_fetch.adoc#problem-statement.

@Vecvec Vecvec added enhancement New feature or request needs-triage labels Jan 7, 2025
@damyanp damyanp moved this to Triaged in HLSL Triage Jan 7, 2025
@damyanp damyanp added this to the Shader Model Backlog milestone Jan 7, 2025
@Vecvec
Copy link
Author

Vecvec commented Jan 8, 2025

This may also require a flag in DirectX like in Vulkan. Should that be opened as a seperate issue, if it should be opened where should I open it?

@damyanp
Copy link
Member

damyanp commented Jan 8, 2025

Thanks - no need for a separate issue.

@damyanp
Copy link
Member

damyanp commented Jan 8, 2025

Marking as a candidate for SM 6.9.

@Vecvec
Copy link
Author

Vecvec commented Jan 9, 2025

Thank you!

@Vecvec
Copy link
Author

Vecvec commented Jan 16, 2025

I would like to write a proposal for this, is there anything which I should discuss first? I think the dxil ops would work the same as Vulkan's so the names would be similar.

@damyanp
Copy link
Member

damyanp commented Jan 16, 2025

We have an internal proposal already, I'll try see if we can make it public yet.

Note that DXIL and SPIR-V have some unique differences that mean we shouldn't expect a 1:1 mapping from SPIR-V to DXIL operations here. IIRC, some of the work in #361 will impact this, since the right design may be able to build on the long-vectors feature (I remember us thinking that before we designed the long-vectors feature so that thinking may be out of date.

@Vecvec
Copy link
Author

Vecvec commented Jan 16, 2025

OK, it will be nice to have the proposal public so I can figure out how to integrate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Triaged
Development

No branches or pull requests

2 participants