나는 SDK, 특히 Island11 프로젝트 에서 Nvidia의 예제를 연구하고 있으며 파도 높이의 상태에 따라 반사를 위아래로 수정하는 HLSL 코드에 대해 궁금한 것을 발견했습니다.
당연히 간단한 코드 단락을 검토 한 후 :
// calculating correction that shifts reflection up/down according to water wave Y position
float4 projected_waveheight = mul(float4(input.positionWS.x,input.positionWS.y,input.positionWS.z,1),g_ModelViewProjectionMatrix);
float waveheight_correction=-0.5*projected_waveheight.y/projected_waveheight.w;
projected_waveheight = mul(float4(input.positionWS.x,-0.8,input.positionWS.z,1),g_ModelViewProjectionMatrix);
waveheight_correction+=0.5*projected_waveheight.y/projected_waveheight.w;
reflection_disturbance.y=max(-0.15,waveheight_correction+reflection_disturbance.y);첫 번째 추측은 수직 섭동 (파도)을받을 때 평면 반사를 보상하고 반사 된 기하학을 아무것도없는 곳으로 옮기고 물이 마치 하늘이없는 것처럼 렌더링됩니다.
이제는 지형의 녹색 / 회색 / 노란색 반사가 물의 기준선으로 채워져있는 것을 볼 수있는 하늘입니다. 내 문제는 이제 그 배후의 논리가 무엇인지 정확히 알 수 없다는 것입니다. 웨이브 / 워터 지오메트리 점의 실제 월드 공간 위치를 투영 한 다음 -.5f를 곱하여 같은 점을 다시 투영하기 만합니다. 이번에는 y 좌표가 -0.8 (왜 -0.8?)로 변경되었습니다.
코드의 단서는 중복이 있기 때문에 시행 착오를 통해 도출되었음을 나타냅니다. 예를 들어, 저자는 투영 된 y 좌표의 음의 절반을 w 나누기 후 가져옵니다.
float waveheight_correction=-0.5*projected_waveheight.y/projected_waveheight.w;그런 다음 두 번째 점에 대해서도 동일하게 수행합니다 (긍정적 인 것, 어떤 종류의 차이를 얻기 위해 가정합니다).
waveheight_correction+=0.5*projected_waveheight.y/projected_waveheight.w;2로 나누기를 제거해도 품질 개선에 차이가 없습니다 (누군가 나를 수정하려는 경우 수행하십시오). 그것의 요점은 예상되는 y의 차이 인 것처럼 보입니다. 왜 그렇습니까? 이 중복성과 겉보기에 임의의 -.8f 및 -0.15f 선택은 이것이 휴리스틱 / 추측 작업의 조합 일 수 있다고 결론을 내 렸습니다. 이것에 대한 논리적 인 토대가 있습니까? 아니면 필사적 인 해킹입니까?
다음은 가장 작은 테셀레이션 수준에서 코드 조각으로 해결되는 초기 문제의 과장입니다. 바라건대, 내가 놓친 아이디어를 촉발시킬 수도 있습니다. -.8f는 평면적으로 반사 된 지오메트리 렌더링을 샘플링하는 텍스처 좌표를 방해하는 정도를 추론하는 기준 높이 일 수 있으며 -.15f는 보안 측정 값의 하 한일 수 있습니다.
