问题标签 [orthographic]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
1 回答
160 浏览

xtk - XTK 中的正射投影

所以我正在使用 XTK 开发一个应用程序,允许用户在一个渲染器中查看多个 3D 网格。问题是它使用透视相机而不是正交相机,这会导致平移稍微“旋转”网格。有没有人成功地让 XTK 在不修改源代码的情况下进行正交渲染?我宁愿不修改它,但如果必须,我会的。谢谢!

0 投票
0 回答
126 浏览

android - 我的精灵似乎是从屏幕的左到右生成的?

所以,我的问题是我的精灵似乎是从屏幕左侧生成到屏幕右侧(我正在使用三星 s3 来测试我的应用程序)。它们应该从屏幕顶部下来。我正在使用 Libgdx,我知道 0 从左下角开始。

这是我的代码来设置他们应该从哪里开始..

这是我的 MainGame 类...(以及它的上半部分)

这是我的正射相机设置(上半部分)

这是我完整的 OrthoCamera 课程

还有我完整的 VirtualViewport 课程

这是我的 Enemy Class (应该下降的对象)

0 投票
1 回答
84 浏览

java - 不同尺寸手机上的正交相机屏幕

我的正交相机被初始化为尺寸 540x960(我的 HTC One 屏幕的尺寸)。但是,当我在另一部屏幕更大的手机上尝试它时,每当我点击移动我的纹理时,我触摸的位置和纹理移动到的位置都会出现偏移。我应该使用不同的尺寸技术吗?比如通过 Gdx.graphics.getWidth() 和 .getHeight() 来调整大小?

从下面的评论:

0 投票
1 回答
2020 浏览

2d-games - 这个视角怎么叫

《Hyper Light Drifter》等游戏有伪等距视角:

在此处输入图像描述

这种观点怎么称呼?有没有我可以查到的“规则”?

谢谢。

0 投票
1 回答
293 浏览

three.js - Three.js 正交相机重叠的对象闪耀通过

在我的场景中,我使用的是正交相机和 WebGLRenderer ( new THREE.WebGLRenderer({ antialias: true, preserveDrawingBuffer: true }))。此代码创建了两个球体:

new THREE.Mesh( new THREE.SphereGeometry(1, 64, 64), new THREE.MeshLambertMaterial({ color: 0xffffff }) )

我用另一个代码片段将它们彼此分开,并且由于某种原因,它们彼此发光,如图所示,即使它们具有相同的大小和相同的位置,除了一个轴。

场景

有谁知道为什么会这样以及我该如何解决?

0 投票
1 回答
140 浏览

opengl - 正交投影+透视投影相互裁剪

组合正交投影和透视投影时出现问题。

我在 3d 对象上绘制纹理:

在此处输入图像描述

我想这与剪裁值有关:

我希望有人可以帮助我解决这个问题。它不是一个大问题,但它困扰着我。

0 投票
1 回答
405 浏览

android - 在 android 设备上获取正确的坐标

我正在 LIBGX 中编写一个按钮。它在桌面上运行良好,但是当我在 android 上启动它时,我必须在不同的地方触摸才能触发它(我使用的是真正的 Android 设备,而不是 AVD)这是一张描述它的图片:

在此处输入图像描述

在 TouchDown 代码下方:

没有 Vector3 我也遇到了同样的问题,我开始使用它是因为有人建议它,但没有解决太多。这是相机的声明:

我做了一些研究,但找不到正确的解决方案,而且我发现相机(正交、现实世界等)非常令人困惑。我会继续挖掘,这花了几个小时,不得不提出这个问题。我希望有人能指出我正确的方向。

0 投票
1 回答
1131 浏览

java - What is the source of these pixel gaps in between identical vertices in OpenGL's Ortho? How can I eliminate them?

Despite passing equal (exactly equal) coordinates for 'adjacent' edges, I'm ending up with some strange lines between adjacent elements when scaling my grid of rendered tiles.

My tile grid rendering algorithm accepts scaled tiles, so that I can adjust the grid's visual size to match a chosen window size of the same aspect ratio, among other reasons. It seems to work correctly when scaled to exact integers, and a few non-integer values, but I get some inconsistent results for the others.

Some Screenshots:

The blue lines are the clear color showing through. The chosen texture has no transparent gaps in the tilesheet, as unused tiles are magenta and actual transparency is handled by the alpha layer. The neighboring tiles in the sheet have full opacity. Scaling is achieved by setting the scale to a normalized value obtained through a gamepad trigger between 1f and 2f, so I don't know what actual scale was applied when the shot was taken, with the exception of the max/min.

Attribute updates and entity drawing are synchronized between threads, so none of the values could have been applied mid-draw. This isn't transferred well through screenshots, but the lines don't flicker when the scale is sustained at that point, so it logically shouldn't be an issue with drawing between scale assignment (and thread locks prevent this).

Scaled to 1x:

1x

Scaled to A, 1x < Ax < Bx :

Ax

Scaled to B, Ax < Bx < Cx :

Bx

Scaled to C, Bx < Cx < 2x :

Cx

Scaled to 2x:

2x

Projection setup function

For setting up orthographic projection (changes only on screen size changes):

For the purposes of the screenshot, nw is 512, nh is 384 (implicitly casted from int). These never change throughout the example above.

General GL drawing code

After cutting irrelevant attributes that didn't fix the problem when cut:

Grid drawing code (dropping the same parameters dropped from 'draw'):

Between the tiles and the platform specific code, vectors' components are retrieved and passed along to the general drawing code as pasted earlier.

My analysis

Mathematically, each position is an exact multiple of the scale*tilesize in either the x or y direction, or both, which is then added to the offset of the grid's location. It is then passed as an offset to the drawing code, which translates that offset with glTranslatef, then draws a tile centered at that location through halving the dimensions then drawing each plus-minus pair.

This should mean that when tile 1 is drawn at, say, origin, it has an offset of 0. Opengl then is instructed to draw a quad, with the left edge at -halfwidth, right edge at +halfwidth, top edge at -halfheight, and bottom edge at +halfheight. It then is told to draw the neighbor, tile 2, with an offset of one width, so it translates from 0 to that width, then draws left edge at -halfwidth, which should coordinate-wise be exactly the same as tile1's right edge. By itself, this should work, and it does. When considering a constant scale, it breaks somehow.

When a scale is applied, it is a constant multiple across all width/height values, and mathematically shouldn't make anything change. However, it does make a difference, for what I think could be one of two reasons:

  • OpenGL is having issues with subpixel filling, ie filling left of a vertex doesn't fill the vertex's containing pixel space, and filling right of that same vertex also doesn't fill the vertex's containing pixel space.
  • I'm running into float accuracy problems, where somehow X+width/2 does not equal X+width - width/2 where width = tilewidth*scale, tilewidth is an integer, and X is a float.

I'm not really sure about how to tell which one is the problem, or how to remedy it other than to simply avoid non-integer scale values, which I'd like to be able to support. The only clue I think might apply to finding the solution is how the pattern of line gaps isn't really consistant (see how it skips tiles in some cases, only has vertical or horizontal but not both, etc). However, I don't know what this implies.

0 投票
1 回答
250 浏览

opengl - z 轴的意外方向(无视图,无投影矩阵)

我试图了解如何使用 OpenGL 绘制对象。问题很简单,但我仍然无法在任何地方找到明确的答案(或者我完全愚蠢:))。让我描述一下这个问题。

1)我只是在屏幕上放了 2 个三角形。三角形的坐标(x,y,z,w)如下:

2)我没有使用也不查看,也没有投影变换

3)我将每个三角形的“默认”颜色作为顶点属性之一传递,并使用变量将它们简单地绕过到片段着色器。Triag1 为蓝色,Triag2 为红色

网络上的所有教程都说OpenGL使用右手坐标系并且Z轴指向“屏幕外”。因此,考虑到我的对象各自的 z 坐标,我希望在它后面看到一个较小的红色三角形和一个较大的蓝色三角形。怎么从来没有发生过。我只能看到一个大胖蓝色三角形。

如果我交换我的三角形各自的 z 坐标(Triag1 得到正 z 坐标,Triag2 得到负 z 坐标)我会看到我期望看到的。但。这意味着 Z 轴以某种方式指向屏幕,而不是在屏幕之外。

有经验的人可以解释一下我错过了什么基本方面吗?

PS 没有 GLUT,没有 GLM,没有调用设置各种 OpenGL 矩阵。仅“将顶点传递给 GPU - 启用着色器程序 - 绘制事物”

0 投票
2 回答
150 浏览

java - LibGDX正交相机:使边框黑色而不是白色(java)

我正在使用 LibGDX 正交相机类来处理不同的屏幕尺寸,它对我来说效果很好。我唯一的问题是当设备没有按比例拉伸时屏幕周围的边框。

我不太介意边框,唯一困扰我的是边框的颜色。我认为如果它是黑色而不是白色会更好看。有什么办法可以改变吗?

我还发布了另一个关于 android 触摸处理的问题,但从未得到解答。如果有人能回答这个问题,那就太好了。我不想再问了,我不想看起来像垃圾邮件。我的问题