-
Notifications
You must be signed in to change notification settings - Fork 139
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
3d projection is not correctly adjusted with non centre origin #417
Comments
Hmmmmm. Yes this is an interesting one. Confirmed this is a bug, I can reproduce it. My math skills are terrible but I think the line you've highlighted looks like the culprit. I would have assumed that multiplying by the origin.y would do it something like:
Did you already try that? |
Yeh I've tried that amongst other things. Video demonstrating how the bounds are effected when adding the adjustment you suggested Rob. My maths is also pretty poor unfortunately, I've been meaning to post to stack overflow, hopefully there's some mathematicians out there. I think it has something to do with the 3d bounds having iso coordinates |
I have zero Idea what I am talking about but it's not something screwy like "their origin taken from the bottom left" and "the other co-ords mapped from the top left" or something similarly really infuriatingly simple is it? Just a thought. |
The 3d bounds uses the same translation which is by default .5,.5,.5
It's odd because the debug 3dbounds are drawn correctly but that's calculated from the 3dpoly aabb, this is done in IgeViewport by the paintAabbs method. This is the best I've come up with but it's junk really.
I've posted to stackoverflow here: http://stackoverflow.com/questions/25261109/calculating-2d-origin-offset-in-30-60-isometric-world |
I also had issues with isometric depth sorting. I left origin at the default [0.5,0.5,0.5] and made all my entities "flat", i.e. size3d(20, 20, 1). I then used the 2d anchor() to correctly position the texture at the entity's origin. By the way, in case you wonder, I'm using depthSortMode(2), which means simple x+y+z depth sorting. The reason is I couldn't get rid of overlapping 3d bounds and depthSortMode(2) was the fastest and most reliable anyway :-) |
Hey sorry I've not got back to your about this, the reason I had for moving the origin is because my scenery is incorrectly placed when comparing with the placement in the Tiled editor. I think that has something to do with the difference in the coordinate system used. It involved creating a child entity within my SceneryObject class (which extends IgeEntity).
I also then added some wrapper methods that forward mouse events from the model to the objects main class. The normal originTo adjustment I mentioned in my previous post doesn't work I believe because of confusion of coordinates. The origin is adjusted relative to the 2d texture and therefore by a 2d vector. 3d bounds are obviously drawing in iso coordinates with 3d vectors. I think we just need to figure out the amount of x/y adjustment in pixels and convert it iso world values. |
I tried to understand why the entity was not placed correctly when I set 3D bounds like (32, 32, 32). I found out the texture is always centered at the center of the bounding box on the screen. If you use .anchor() you can adjust the texture position in 2d screen coordinates. The bug that we are looking for shows when you use origin(0.5, 0.5, 0) or something similar. By the way I wonder how you place your entities correctly because with origin(0.5, 0.5, 0.5) and geometry.z > 1 (set by size3d()) your bounding box extends below the “surface” of the z=0 plane. Could this be the source of your troubles? |
Hi,
There is an issue with the _projectionOverlap and a _isBehind methods of IgeEntity
The methods only work when the entity has the standard centre origin.
If the entities origin is adjusted the methods return incorrect results.
I've been trying to resolve this myself, but I'm going round in circles, trying various apporaches but the numbers results get even more confusing. I'm reaching out for some help.
I believe this is the section that's at the root of the issue.
Lets look at one of the lines...
This intends to calculate the top left vertex.
That's fine when the origin y is .5, however change that to .7
and it no longer calculates the top left vertex as intended.
Thanks
Rob
The text was updated successfully, but these errors were encountered: