Pixi.js: 컨테이너에 고정 경계를 설정하는 옵션 제공

컨테이너에는 영역과 고정 된 경계가 없으며 자식 모음 일 뿐이며 기본 PIXI 동작입니다. 경계를 수정하려면 자체 컨테이너를 확장하고 "calculateBounds"메서드를 재정의합니다.

영역과 고정 경계가없고 기본적으로 데이터 구조 일 경우 렌더링에 영향을주지 않아야합니다 (너무 큰 개체를 iframe에 넣는 경우와 유사하게 iframe이 더 커지지 않음). . 예제에서는 분명히 그렇습니다. 나는 예제의 잘못된 논리를 비난하기가 어렵습니다. 고정 된 경계 옵션이없는 것은 문제의 원인을 찾지 못하지만 문제는 분명히 존재합니다.

"오프 스크린"요소를 구현할 것을 어떻게 제안 하시겠습니까?

어쨌든 경계가 필요한 이유는 무엇입니까?

예를 보셨습니까? 이상한 동작은 drawDebugLines 가 실행되고 "아이콘"컨테이너에 선을 그릴 때마다 해당 컨테이너가 커진다는 사실로 인해 발생합니다. 이는 컨테이너 치수 (너비 / 열, 높이 / 행)에 따라 달라지기 때문에 스냅 지점을 엉망으로 만듭니다.

두 가지 문제를 일으키는 렌더링 요소에 스냅을 매핑하면 렌더러는 화면 크기, 방향, 픽셀 밀도 및 그리기 요소의 사용자 지정 치수에 따라 달라집니다. 여기에는 더 크고 (예 : 화면 밖에서 슬라이드 할 수있는) 더 작은 항목 (예 : 데스크톱 1과 데스크톱 2를 동시에 표시하는 경우)이 포함될 수 있습니다. 이러한 모든 경우에 스냅 및 기타 제약 조건은 유지되어야합니다. .

lel.width = wonderfulRectangle.width * 0.8;
lel.height = wonderfulRectangle.height * 0.9;

왜 그것을 상수로 사용하지 않습니까? 다음과 같이 전역 적으로 설정할 수 있습니까?

var globalRect = new PIXI.Rectangle(0, 0, renderr.width/renderer.resolution, renderer.height/renderer.resolution);

크기를 조정할 때마다 해당 사각형을 업데이트하고 작업하십시오. "lel.width"및 "lel.height"가 필요한 이유는 무엇입니까?

LEL. 그건 아무 상관이 없습니다. 그냥 움직일 수있는 스프라이트 일 뿐이고 원본 이미지가 너무 커서 사각형에 맞춰야하기 때문에 너비와 높이를 설정하고 있습니다. 에서 코드를 보면 해당 "아이콘"의 기본 컨테이너가 desktop1이고 아이콘을 스냅하려고하는 컨테이너 인 것을 볼 수 있습니다. 그 것은 desktopLayer에 속하고 desktopLayer는 내가 무대에 놓은 것입니다.

내가 에뮬레이트하려는 것은 여러 스 와이프 가능한보기와 바탕 화면 배경 위에 아이콘 그리드가있는 Android Launcher 화면의 동작입니다.

return new PIXI.Point(snapPosX.clamp(0, target.parent.width), snapPosY.clamp(0, target.parent.height));

나는 아직도 당신이 원하는 것을 이해하지 못합니다. PIXI 컨테이너 경계는 예상대로 정확히 작동합니다. 이 실수를 한 것은 당신이 처음이 아닙니다.

오 메이커의 숨결, 더 이상 할 수 없다. 누구든지 예제를보고 rageface를 움직여서 왜 그 선이 엉망이되는지 그리고 PIXI의 버그 / 누락 된 기능인지 아니면 코드에 실수가 있는지 말해 줄 수 있습니까?

선이 실제로 컨테이너 너비와 높이에 영향을 미치고 해당 속성을 사용하여 처음에 선을 그리기 때문이라고 생각했습니다.

또한 codepen이 더 이상 작동하지 않습니다. 이유는 무엇입니까?

예, 실수로 초기화 호출을 주석 처리했기 때문에 나에게도 망가졌습니다. 예, 맞습니다. 그게 제가하는 일이며 그리드를 시각적으로 반영하기 위해 선을 그리는 다른 방법은 없습니다. 그렇다면이 선을 그리기 위해 정확히 무엇을 제안 하시겠습니까? 연결된 렌더링 된 컨테이너의 치수를 항상 복사하고 스냅 지점 및 기타 위치를 파생하는 데 사용하는 별도의 메타 전용 Rectangle 개체를 설정 하시겠습니까? 그것은 문제를 해결하는 것이 아니라 과잉 엔지니어링하는 것처럼 보입니다. 컨테이너가 일반 DOM 요소처럼 "오버플로"를 가질 수없는 이유가 있습니까?

나는 해결책이 없기 때문이 아니라이 비논리적 인 행동에 대한 정당성을 볼 수 없기 때문에 이것을 이슈로 게시했습니다. 특히 선이 실제로 컨테이너 경계를 벗어나지 않기 때문에 가장자리에서 가장자리로 그려집니다. 내가 구축중인 제품에서 사용자는 콘텐츠와 많은 상호 작용을해야합니다. 장면의 모든 개체에 대해 "참조 사각형"을 설정해야하는 경우 코드가 매우 지저분하고 유지 관리하기 어려울까 걱정됩니다. .

내 코드에 "실수"가 있다고 언급하셨습니다. 그 실수는 무엇입니까? 나는 매우 철저히 검색했지만 잘못된 논리를 찾을 수 없습니다.

변경되는 "너비 / 높이"대신 전역 변수를 사용하십시오. 필요한 경우 해당 변수를 업데이트하십시오.

var globalRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

"로컬"경계를 원하면 만들지 만 pixi와 동일한 변수를 사용하지 마십시오.

container.myRect = new PIXI.Rectangle(0, 0, renderer.width/renderer.resolution, renderer.height/renderer.resolution);

실수는 PIXI에 레이아웃이 전혀 없다는 것입니다. "너비"와 "높이"는 다른 의미를 갖습니다. 자식이 영향을주기 때문에 부모 너비 높이로 자식 좌표를 고정 할 수 없습니다.

PIXI가 그래픽 내부에 그린 일부 직사각형의 너비 / 높이를 원하는지 알 수있는 방법은 없습니다. 경계에 대한 유일한 합리적인 논리는 그 안에있는 모든 것을 가져 오는 것입니다.

각각 (w = 10, h = 10), 하나는 (0,0)에 있고 두 번째는 (100000, 100000)에있는 두 개의 스프라이트가있는 컨테이너가 있다고 상상해보십시오. 컨테이너의 너비와 높이는 얼마입니까? 또한 우리가 어떻게 든 경계를 수정하더라도 어떤 영향을 미칠까요?

그리고 어떻게 든 너비와 높이를 변경하려면 컨테이너 내부의 요소에 어떤 영향을 미칠까요?

농담이 아닙니다. 다른 API 디자인을 상상하기가 정말 어렵습니다. 몇 가지 아이디어가 있으면 레이아웃에 대한 추가 구성 요소가 될 수 있습니다. 여기에 작성하십시오. 우리는 일부 GUI가 아닌 스테이지 렌더링을 다루고 있다는 것을 기억하십시오. 성능은 실제 문제입니다.

안녕하세요 @megakoresh , 여기에서 혼란을 일으키는 원인을 알고 있다고 생각합니다. pixi의 주요 목적은 2D 객체를 렌더링하는 것이므로 거의 모든 API가이를 위해 조정됩니다. 경계는 특히 혼란 스러울 수 있습니다.

pixi에서 Sprite의 경계는 텍스처에 의해 정의됩니다. 즉, 렌더링 된 객체의 최종 결과 크기입니다. 유사하게, 컨테이너는 _not drawn_이므로 그 경계는 포함 된 자식에 의해 정의됩니다. 특히, 그 아이들의 경계에 의해. Graphics 객체의 경우 경계는 그 안에 그리는 지오메트리에 의해 정의됩니다. 현재 경계 외부의 Graphics 객체에서 다른 직사각형을 그리면 경계가 확장되어 새로 그린 형상을 포함합니다.

그것이 의미가 있기를 바라며 Pixi에서 경계가 어떻게 구성되는지에 대한 빠른 개념을 제공합니다.

이제, 특히 귀하의 예를 들어, 귀하의 문제는 Graphics 객체에 대해 경계가 작동하는 방식에 대한 오해에서 비롯된 것이라고 생각합니다. 그리드를 그리는 것이 녹색 사각형 ( wonderfulRectangle )을 포함하는 Graphics 개체 ( desktop1 )의 경계를 변경한다는 사실이 누락되었다고 생각합니다.

첫 번째 그리기 후 그리드가 뷰포트의 크기를 벗어나 확장되는 것을 볼 수 있습니다.

그러면 뷰포트 외부 지오메트리를 포함하도록 상위 Graphics 객체 ( desktop1 )의 경계가 확장됩니다. 이렇게하면 너비가 더 커져 다음 그리드 계산이 중단되고주기가 계속됩니다. 선에는 두께가 있으므로 너비를 차지합니다.

이 문제를 해결할 수있는 몇 가지 방법이 있습니다. 마음에 떠오르는 한 가지는 그리드가 뷰포트의 전체 크기를 채우므로 부모의 크기가 아닌 뷰포트의 크기를 사용한다는 것입니다. 즉, 뷰포트 외부에 더 많은 지오메트리를 그릴 때 그리드 계산이 변경되지 않습니다. 렌더링 뷰포트는 크기를 변경하지 않기 때문입니다.

옵션이 아닌 경우, 예를 들어 그리드 영역은 뷰포트의 크기가 아닙니다. 그리드 영역의 "알려진 크기"를 기반으로 계산을 수행 할 수 있습니다. 나는 Ivan이 정적 Rectangle 인스턴스를 사용하는 것에 대해 말하려고 한 것이라고 생각합니다. 기본적으로 그리드가 800x600이라고 결정하고 장면에서 실제 렌더링 된 오브젝트 경계를 실행 한 것을 기반으로 계산을 수행합니다.

내가 설명한 뷰포트 메서드를 사용하도록 코드 펜을 업데이트했습니다. 더 궁금한 점이 있으면 알려주세요!

http://codepen.io/anon/pen/yarVwm?editors=0010

LOL k. 그래서 여러분의 힘을 합쳐서 저는 문제의 핵심을 이해하고 있다고 생각합니다. 저는 라이브러리가 캔버스 라이브러리와 함께 자주 합쳐지면 같은 것이라고 생각했지만 분명히 그렇지 않다고 생각했습니다. 그런 다음 시각적 개체 그룹화를 처리하고 오버플로와 같은 것은 범위에 포함되지 않고 간단합니다 (라이브러리를 더 많이 배울 때 플러그인을 만들 수 있음). PIXI 자체가 처리하는 동안 직접 처리해야합니다. 화면에 표시하는 것뿐입니다. 사건이 종결되었습니다. 감사합니다.

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를여십시오.