Closed GoogleCodeExporter closed 8 years ago
i guess you cant use wiki markup in tickets then!
Original comment by dc.pik...@gmail.com
on 16 Aug 2011 at 9:01
in theory:
To archieve this, the decal's normal must have the same orientation as the
camera's direction vector.
If there is an issue with frontside/backside and therefore the decal being
culled away the direction of the decal's normal must match the camera's
negative direction, as well.
I don't know if decals have a concept of a normal, but they sure have vertices
(or at least an origin, h and w dimensions, and another 3d attribute) from
which the normals could be calculated?
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 9:21
"To archieve this, the decal's normal must have the same orientation as the
camera's direction vector."
-> craps...
To archieve this, the decal's normal must have the same orientation as the
vector between the camera's position and the decal's center. This way the
decal's offset from the camera's viewing center is taken into calculation as
well.
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 9:26
decals seem to be viewable from any angle (no back culling), so dont think the
normals will be a big problem?
Original comment by dc.pik...@gmail.com
on 16 Aug 2011 at 9:43
right, forget the note on culling I mentioned.
The decal's normal is just for calculation of the needed rotation angle round
the y-axis.
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 9:54
Needed: rotation angle alpha around decal's center
In our case we just have to take the x,z plane into concideration.
I have attached a scan so we get the naming convention right to issue the
formulas.
We could get the angle by using trigonometric laws for arbitrary angled
triangles that are made up by the vectors shown in attached scan (decal's
normal, a vector camposition->decalcenter, and the connection vector decal's
normal->cam's position).
For trigonometric calculations only the vector's length are relevant which can
be calculated by libGDX functions.
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 10:28
Attachments:
[deleted comment]
I mentioned DecalSprite's class having an empty method faceCamera which could
be called in DecalWall demo by
wall.faceCamera(oCam)
once it is filled with the maths above.
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 10:59
is x/z all we need? potentially if the camera is a bit from above maybe we
need all three axes?
but for 95% of uses just the Y rotate should be fine i think...
Original comment by dc.pik...@gmail.com
on 16 Aug 2011 at 11:04
I thought the Decals should stay perpendicular to the floor and just rotate
round y Axis to face the camera.
Calculating everythin in 3d would take care of facing the cam in all 3 axis.
Depends on what you'd like to have...
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 5:56
In the end it turned out being a lot more down to earth as expected.
It's just 3 lines of code actually *sigh*
documented it here:
http://code.google.com/p/libgdx-users/wiki/decalsLookAt
and opened enhancement request here:
http://code.google.com/p/libgdx/issues/detail?id=393
/closed
Original comment by radiok...@gmx.de
on 16 Aug 2011 at 7:37
Original issue reported on code.google.com by
dc.pik...@gmail.com
on 16 Aug 2011 at 8:56