Friday, June 29, 2012

On Filtering the Noise from the Random Parameters in Monte Carlo Rendering




몬테카를로 렌더링 시스템은 훌륭한 이미지를 만들어 낼 수 있지만 낮은 샘플링에서는 많은 노이즈를 만들어 냅니다.

이 연구에서는, 몬테 카를로 시스템에서 사용된 무작위 변수들의 직접적인 영향에 의해 나타나는 이미지 영역의 노이즈를 관찰하여 보다 적은 입력 샘플 값으로부터 함수 관계를 추정함으로써 동일한 몬테카를로 노이즈를 만들고자 합니다.

이를 위해서 렌더링 시스템을 블랙박스라고 간주하고 시스템의 입력과 출력 사이의 통계적 종속성을 계산합니다.

그런 다음 몬테카를로 방법에 의해 영향을 받는 샘플 값의 중요도를 감소시키기 위해 이미지 공간에 적용시 이 정보를 사용하여 cross-bilateral 필터를 사용하여 무작위 변수에 의해 나타나는 노이즈만 제거하고 씬의 중요한 디테일은 보존하게 합니다.

샘플 값들 사이의 함수관계를 사용하는 과정과 몬테카를로 노이즈를 필터링 하기 위한 무작위 변수 입력 과정은 무작위 변수 필터링 (RPF) 라고 불리며, 이 방법을 통해서 단지 몇 분만에 수천배나 많은 샘플로 렌더링 된 이미지와 유사한 이미지를 만드는 방법을 설명합니다.

나아가서, 이 알고리즘은 무작위 변수를 위해 어떠한 물리적 의미를 지정하지 않았기 때문에 일반적이며, 몬테카를로 방법의 다양한 효과들(피사계 심도, 에이리어 광원, 모션블러, 패스트레이싱 등을 포함한)에 적용가능 합니다.

여기 이전의 접근법으로 만들어진 것들에 비해 높은 품질을 가지지만 낮은 샘플링율로 만든 스틸 이미지와 애니메이션 시퀀스를 공개합니다.

Wednesday, June 27, 2012

Materials to Editor

Materials to Editor


재질 편집기를 비운 다음 선택한 오브젝트의 재질들로 자동으로 채워줌


Saturday, June 23, 2012

MeshDeform

MeshDeform

메쉬 오브젝트의 윤곽을 따라서 오브젝트를 디폼 시켜줍니다.
메쉬에는 작동하지 않는 surfDeform 이나 patchDeform 에서 힌트를 얻었다고 합니다.



Friday, June 22, 2012

Maxwell Bench & Render Calculator

맥스웰 초창기 시절에 Wishlist 에 cinebench 와 같은 maxwellbench 가 있었으면 좋겠다고 글을 쓴 적이 있습니다.

그런데 개발팀에 전혀 먹히지 않았고, 그 사이 생뚱맞게 fry render 에서 먼저 frybench를 선보였습니다.

매우 실망스러워서 "봐라, fry 에서 먼저 하지 않았냐?" 라고 외쳤지만

별 반응이 없었더랬습니다.

이번에 나온 2.7 버전에는 기존처럼 씬을 불러와서 벤치마크를 하는게 아니라

맥스웰 뷰어에서 메뉴를 통해 Benchwell 을 실행시킬 수 있습니다.

씬 제작자(Herve&Tom) 보호를 위해 씬을 제공하지 않고, 온라인으로 로딩을 하여

최종결과만 보여주고, 자동으로 결과를 포스팅 할 수 있도록 해 줍니다.

http://www.maxwellrender.com/index.php/benchwell/id/272




이렇게 실행이 되고, 끝나면 포스팅을 할 것인지 물어본 다음

등록을 마치면 뷰어에 이미지가 나타납니다.



상당히 괜찮은 방법인 듯 합니다만 트라이얼버전에서도 동일하게 워터마크 없이 나오는지는 아직 모르겠습니다.

트라이얼이 나와봐야...


그리고 또 하나 추가된 메뉴가 '렌더링 시간 계산기'

우선 mxi 파일을 하나 불러와 봤습니다.

샘플링이 12.97 까지 완료된 파일인데 해상도를 정해주고 시간계산 옵션으로 지정한 다음

원하는 샘플링 레벨을 13으로 지정했더니 22초가 걸린다고 나오네요.




이번엔 20까지 높여서 얼마나 걸리나 봤더니 8시간 11분 남았다고 나옵니다.



물론 계산 옵션을 Time 이 아닌 Sampling Level 로 지정하고,

원하는 종료시간을 지정하면 최종 샘플링 레벨을 계산해 줍니다.


예전에 누군가가 별도로 계산기 툴을 만들었었는데

이제 아예 기본기능에 포함이 되었네요.

마이너 버전업 (0.1) 치고는 꽤 괜찮은 버전업이라고 생각이 됩니다.

Maxwell 2.7 에서 Mxs, Mxi 의 file size comparison

2.6 에서

MXS 297,628 KB
MXI  129,672 KB

2.7 에서

MXS  125,989 KB  ( 약 57.7퍼센트 감소)
MXI    48,791 KB   ( 약 62.4퍼센트 감소)


:)

Instance-Align

Instance-Align

조명을 추가하고, 의자나 탁자를 교체하는 등의 인테리어 시각화에 유용한 스크립트


1. 복제할 오브젝트를 선택하고

2. 타겟들을 선택한 다음, click pick targets -> ok

3. 정렬방식 선택:

- CenterXYZ

- ZCenterXY (Align minZ of source to maxZ targets)

- Pivot align

- match all transform

실행 후에는 새 오브젝트들이 선택이 되어짐.
그룹이나 열린 그룹에도 작동



Thursday, June 21, 2012

Wednesday, June 20, 2012

V-Ray for 3ds Max 라이센스 정책 변경사항


일전에 아래와 같은 글을 쓴 적이 있습니다.
http://maxwellsandy.blogspot.kr/2012/02/v-ray.html

글로벌 정책으로는 하나의 V-Ray for 3ds Max 의 라이센스로 10대까지 DR을,

그리고 무제한 네트웍렌더링(백버너 등 사용)이 가능한데 반해

국내 정책은 라이센스당 5대까지 DR과 5대까지 네트웍렌더링밖에 지원이 되지 않아서

카오스포럼에 왜 국내에만 별도의 정책이 있느냐고 항의까지 한 적이 있습니다.


이제 이 제한들 중 DR 5대 제한은 그대로이나 네트웍 렌더 5대 제한이 없어졌습니다.

http://www.chaosgroup.com/kr/2/vray.html

제품 소개 링크를 가 보면

카오스 그룹 제품들은 한 대의 장비 당 라이선스가 적용되는데, 하나의 V-Ray for 3ds Max 라이선스로는 하나의 3ds Max 플랫폼 안의 툴들과V-Ray GUI를 사용할 수 있고, 하나의 로컬 렌더 잡을 진행할 수 있습니다. 그리고, Backburner와 같은 렌더 잡 메니저 또는 "3dsmaxcmd.exe"를 사용해서 무제한의 render slave들로 네트워크 렌더링을 할 수 있습니다. 또한, V-Ray DR spawner를 사용해서 Distributed rendering (분산 렌더링)을 위해 최대 5개의 slave들을 사용할 수 있습니다.




라는 내용으로 변경이 되었습니다.

아직 DR 5대를 손해를 보는 정책이긴 합니다만 그래도 긍정적인 변화라고 생각이 듭니다.

올바른 방향으로 바뀔 수 있도록 애쓰신 모든 분들께 감사를,




                                                                      ..........여전히 PC1대만 사용하는 1人이

Tuesday, June 19, 2012

Pflow LookAt Script

Pflow LookAt Script

파티클을 씬 오브젝트에 정렬시킴. look axis, flip, horizontal rotation, variation 을 지원


Monday, June 18, 2012

Light By Cam

Light By Cam

카메라 뷰에 따라서 조명을 켜고 끄는 스크립트

Geometry projection

Geometry projection


지오메트리 프로젝션. 제목 그대로 한 오브젝트에 다른 오브젝트를 프로젝션 해 주는 스크립트.

Wednesday, June 13, 2012

Unreal 등과 같은 게임엔진 등을 렌더러 대신 사용할 수 있을까?

http://www.chaosgroup.com/forums/vbulletin/showthread.php?68838-Unreal-4&p=553151#post553151

최근 E3 2012 등에서 소개된 유명 게임엔진 영상을 본 사용자가 “쟤네는 어떻게 저렇게 GI를 표현할 수 있지?” 라는 질문에 Vlado씨가 한 답변이 재미납니다.

There are techniques like virtual light sources, volume light fields, reflection shadow maps etc. that help with that. Since your next question might be "why don't you put this in V-Ray", the answer is - these techniques have various drawbacks as well, among them:
= Precalculation - while the final result is rendered in real time, some preprocessing might be required for the scene, which may be quite time-consuming;
= Limited precision - typically you only get general GI solutions which tend to be somewhat blurred. Adding detail to the GI solution might increase the memory and/or processing requirements;
= Limited scope - some algorithms only work for closed spaces with clearly defined boundaries; implementing them when rendering a full-scale landscape for example, would be impossible;
= The number of bounces for true dynamic GI (not precalculated) is typically limited to 1 or 2 at most;
All these things mean that setting up a GI solution for a scene can be a complicated task...
Best regards,
Vlado

가상의 광원들, 볼륨 라이트 필드, 반사 섀도우 맵 등의 기술들이 도움이 되었지. 그럼 다음 질문은 “왜 그럼 V-Ray에 그런 기술들을 사용하지 않아?” 일테고, 내 대답은
이런 기술들은 다양한 문제점들을 가지고 있는데, 특히나
= 사전 연산 – 최종 결과는 실시간으로 렌더링 되지만, 씬을 위한 사전 연산이 필요하게 되는데, 이게 꽤나 시간이 걸릴 것이다.
= 제한된 정확성 – 일반적으로 약간 블러가 되는 GI솔루션만을 얻게 될 것이다. GI솔루션에 디테일을 추가하면 메모리와 연산 요구사항을 증가시키게 된다.
= 제한된 범위 – 일부 알고리즘은 명확히 지정된 경계를 가진 닫힌 공간에서만 작동된다 : 예를 들어 풀 스케일 풍경을 렌더링 할 때 이를 장착하는 것은 불가능할 것이다.
= 실제 다이내믹 GI (사전 연산이 아닌)를 위한 바운스의 갯수는 보통 1이나 2 정도로 제한된다.
이 얘기는 씬을 위한 GI솔루션을 설정하는 것은 복잡한 작업이라는 뜻이다.


뭐 대략 이렇게 설명하고 있습니다.
즉 ‘게임엔진의 실시간 GI효과가 매우 근사하고 사실적으로 보이긴 하지만 실제 씬을 만들어서 GI 를 적용하려는 작업에서 사용하기에는 아직 한계가 많다’ 라고 정리할 수 있겠네요.

다만 이 견해는 V-Ray개발자의 입장에서 본 것이고, 게임엔진 개발자의 입장에서는 또 다를 수도 있겠죠.

Brix 의 후예들

 

재작년에 Brix 라는 맥스/마야 용 타일맵 제작 플러그인이 나온 적이 있습니다.

brix

뭐 이렇게 생긴 인터페이스를 가진 플러그인 입니다.

보통 플러그인이 개발이 되고 나면 맥스나 마야의 버전업이 됨에 따라서 계속해서 새버전을 지원할 수 있도록 개발이 지속이 되어야 하는데

이 플러그인은 그러지 못했습니다.

 

2011년 9월에 올라온 아래 글을 보면

http://www.chaosgroup.com/forums/vbulletin/showthread.php?49192-Brix&p=530787#post530787

맨 처음 Materialwerk 에서 Brix 를 만들 당시 두 사람이 함께 시작을 했습니다.

한 사람(Dieter)은 소프트웨어 개발을 맡았고, 다른 한 사람(Martin)은 라이브러리와 사이트구축 등을 담당했다고 합니다.

2010년 6월에 Brix의 판매를 시작을 했지만 예상과는 달리 판매량이 저조하였고, 결국 2010년 9월에 갈라서서 각자의 길로 가기로 했답니다.

Brix의 개발은 Dieter 가 유지하는 대신 일정 금액을 Martin 에게 지불하기로 했지만 의견이 맞지 않아서 결국 완전히 갈라서게 되었고

Dieter는 소프트웨어 코드를 소유하고, Martin은 사이트와 재질, 상표권, 사이트 등의 권리를 유지하는 것으로 결론이 났다고 합니다.

그렇게 Brix는 더 이상 업그레이드가 되지 못하고 잊혀졌습니다만,

 

올해 초에 CrossMap 이라는 재질 플러그인이 등장을 했습니다.

http://www.vizpark.com/shop/crossmap/

vp_crossmap_header_image_590x300c

Brix의 기능과 인터페이스 등의 유사함을 느낀 사용자들이 예측한 대로

이 플러그인은 Brix의 라이브러리 등을 담당했던 Martin 이라는 사람이 개발한 플러그인 입니다.

Brix 의 등록 사용자들에게는 무료로 제공을 해 준다고 했었죠.

 

최근에 MightyTiles 라는 플러그인이 또 등장을 했습니다.

http://www.zwischendrin.com/en/detail/262

a

예상하신대로 이 플러그인은 Brix의 소프트웨어 코드를 담당했던 Dieter라는 사람이 만든 플러그인입니다.

인터페이스는 Brix와 매우 유사해 보입니다.

 

두 사람은 서로 자신이 Brix의 아이디어를 냈다고 주장하고 있네요.

 

CrossMap 과 MightyTiles는 Brix에서 갈라져 나온 플러그인 이지만

비슷하면서도 다른 기능을 제공하고 있고, 가격 역시 크게 차이가 있습니다.

CrossMap은 39유로, MightyTiles는 180유로입니다.

Tuesday, June 5, 2012

AvizStudioTools - A2Dimage

AvizStudioTools - A2Dimage

사람이나 나무를 2D플랜 형태로 집어넣을 때 랜덤하게 지정할 수 있도록 도와주는 스크립트

Saturday, June 2, 2012

V-Ray Gamma output tests

Saved images using VFB raw image file (EXR)


파일 저장은 V-Ray Frame Buffer의 Raw Image File 설정부분에서 EXR로 자동 저장

VFB를 사용하는 경우, 3ds Max 자체의 Gamma 설정에서 2.2로 설정하고 Output 만 1.0으로 하는 것과 Output 도 2.2로 하는 것에는 차이가 없음.
V-Ray Color Mapping의 Gamma 설정에만 영향을 받음


아래 뷰포트는 VFB 의 화면으로 Color Mapping에서 Gamma를 1.0으로 설정하고 sRGB를 tick한 경우

VFB - Vray gamma 1.0 & sRGB

Friday, June 1, 2012

Select By Diffuse

Select By Diffuse

디퓨즈 색상을 기준으로 씬에 있는 모든 오브젝트를 선택하는 스크립트.
색상 선택은 오브젝트나 컬러 피커를 통해