Lets take for example a class that projects and unprojects between 2D and 3D.
class Projector
{
Point2D projectPoint(const Point3D& worldPoint) const;
Point3D unProjectPoint(const Point2D& screenPoint, const Plane& plane) const;
};
Both methods need to use a Camera object. What would be the preferred way to implement it:
A. pass Camera in Projector constructor
B. pass Camera in each of the class methods.
C. pass Camera in a setter method before using the class methods.
Option A breaks DI because Camera is a newable. Option B means that the same Camera instance is passed in every call. In interfaces with 5-6 methods, passing the same instance to each method will result in less prettier code. Option C will work, however it means that the user of this class need to know that he should set Camera - there is a risk that he will forget to do this and will not understand why the code does not work.
What is the preferred way to implement it?
I would pass the camera in the constructor and have the camera and projector(s) that use it being instances within that scope. It sounds like the scope is defined by the 'point of view'.
Perhaps the camera is the point of view and the projector is a singleton of the camera?
By constructor is definitely, to me, the best. It may be a question of how you get the projector and/or camera. Your inferring a domain constraint, so code the constraint. May be the constraint is that a 'Point of view' has one camera and .... projector(s).
Related
I'm using the C++ Box2D library. I've created a body and have added multiple square fixtures to it. These square fixtures are offset from the body position (similar to what is done in the "multiple fixtures" section here: https://www.iforce2d.net/b2dtut/fixtures).
My idea is for a rendering system to iterate over the fixture and draw them to the screen. However, I can't seem to find a method for retrieving the X, Y and angle of the fixture. When stepping my Box2D world, the body X/Y/rotation position changes which changes the fixture's X/Y/rotation psoition.
Is there an easy way to extract this information from a square fixture? I could do the math myself to derive the position, however, it seems odd that Box2D wouldn't offer a solution to do this.
Fixtures do not have any location or transform on their own.
Shapes have local points (e.g. b2CircleShape has a center, b2PolygonShape has a list of vertices). However, shapes can be reused in multiple fixtures/bodies. Therefore it makes no sense for them to know about any of the fixtures/bodies they are attached to.
To get a shape's location as it is attached to a body in world space, simply use the body's GetWorldPoint method:
body.GetWorldPoint(p);
where p is any local point of a shape attached to that body (e.g. the location of a b2CircleShape or a vertex of a b2PolygonShape).
From wat you described, it sounds like you need a tool to calculate where everything is. I could be wrong on this but the closet thing I seen in the documentation for the product your using is "Ray Casting" and "AABB testing". Both are described in the World Querying section of the documentation.
I'm new to UE4 and am trying to understand some basics concepts around controlling a character pawn. I'm fumbling around trying to implement some character movement logic. I'm going for the basic WASD to move the character forward, back, side to side - like in pretty much every basic first person shooter. I also want the mouse input to rotate the character around.
I've got my own custom PlayerController and Character classes.
Adding the code to move the character around - front, back, sideways - seems to all go in the character class itself. There is a method in there called AddMovementInput that appears to modify the position for me. This also makes me think that the character class "owns" its own location. That makes sense because there could be more than one character class at a time, each at different locations, right?
Adding the code to rotate the character has similar methods for controlling rotation - AddControllerYawInput, AddControllerPitchInput, AddControllerRollInput. Simply looking at the names of the functions suggests that the yaw pitch and roll are "owned" by the player controller. Looking at the docs and comments for the functions further backs that up: "Add input (affecting Yaw) to the Controller's ControlRotation, if it is a local PlayerController." So it would seem, to me, that the yaw pitch and roll are values "owned" by the player controller, right?
As a beginner, this confuses me: I'm confused by the fact that the location is stored in the character itself but the rotation doesn't seem to be.
I am interested to learn how I should "think about" character or pawn movement. I'm just unclear on it and it's causing me to get hung up on the topic.
The intention behind this design is to separate the Control Mechanics from the Character Physics. In terms of writing software, the idea is to decouple the player control's rotation in terms of the gameplay interaction mechanism from the character's rotation inside the game-world physics. For example, I can be aiming upwards while my character's body is somehow leaning downwards -- and so may physically collide with an object positioned beneath it.
See, you are right in your observations regarding "who owns what". You can see that AController, base class of PlayerController, has a member variable ControlRotation of type FRotator. The documentation for this data member says:
ControlRotation (accessed via GetControlRotation() ), determines the
viewing/aiming direction of the controlled Pawn ...
And GetControlRotation() further clarifies:
This is the full aim rotation, which [...] may differ from
the rotation of the controlled Pawn (which may choose not to visually
pitch or roll, for example).
As in, the controller rotation is being kept in separate from anything "rotation related" that the character manages for itself.
This is further supported in the documentation, for example see under Pawn (base class of ACharacter):
Pawn is the base class of all actors that can be possessed by players
or AI. They are the physical representations of players and creatures
in a level.
and under AController:
Controllers are non-physical actors that can possess a Pawn to control
its actions.
I am writing a custom osg::Drawable class which needs to calculate its current distance from the camera's eye when its drawImplementation method is called. It needs to do this in order to determine the optimal number of facets for rendering.
The difficulty is that my drawable can have any number of osg:Transform nodes as parents. I need to apply the transformation of the actual parent that is being applied to the drawable. Using osg::Node::getParents() and/or getParentalNodePaths(), I can determine all possible paths to this drawable, but not the path that was taken.
Is there any way to determine this in OpenSceneGraph? I have dug through the examples and documentation and have not found exactly what I require.
You can do this at cull stage rather than the render/draw stage. You can get the model view matrix from the cull visitor and later determine the distance from this. Since you want this for your custom drawable class, you can do this by attaching a cullcallback.
I know that it is possible to use affine transformations with Qt. But is it also possible to set a complete custom global transformation method?
Use case: Drawing projected geographic points (lat, long) or retrieve mouse events etc. in geographic corrdinates (in the context of a QGraphicsScene/View).
At the moment I use it like that (little bit pseudo code):
MyPoint pt = myProjection(geographicPoint);
QPoint(pt.x, pt.y);
// or, to make it shorter, but essentially it's the same
QPoint p = myProjection(geoPoint);
geoPoint = myBackProjection(mouseEvent.getPoint());
And I'd like to do "register" my transformation methods somewhere so that the QGraphicsView (or whoever is responsible) internally uses these methods before it draws something on the screen.
Or does that neither make sense (because it would introduce problems where I don't expect them, e.g. in calculating distances) nor is it possible?
QGraphicsView uses a QTransform matrix, which is a 3x3 matrix. Therefore you can only do linear transformations. In Qt5/QtQuick or with QtQuick3d you may be able to achieve this with a QML ShaderProgram.
In "pure" Qt4 you would have to derive your own custom class from QGraphicsView, or QAbstractScrollArea or QGraphicsScene and override the paint methods.
A good approach would be to encapsulate this transform in your QGraphicsItem shape() method. Suppose you have a point defined as a pair of latitude and longitude, it would store pairs of lat lon, but its shape method would return projected values (usually in pixel equivalents).
If you feel like it, you could even subclass QPoint to make it geographically aware, thus creating it with latlon, but exposing projected values in its x, y properties.
Ok, so here is what I have:
an abstract "Object" class which I made in a framework to use it as a base class for all 3D objects.
a Matrix4 member of this class which has the sole purpose of storing rotation info for the object.
some functions that multiply the matrix: for each of the yaw, pitch & roll rotations (both global and local), I made a method that multiplies the above rotation matrix with a new matrix.
e.g.: if you locally yaw the object by 45 degrees in CCW direction, then
rotMatrix = newRotationZMatrix(45) * rotMatrix;
What I would like to know is what is the best way of getting the global rotation of the object as a vector - generally speaking, how do you get the rotation angles around X,Y and Z from a transformation matrix that contains JUST rotations.
There are techniques to obtain that, just get the euler angles from a rotation matrix, it involves a bit of math. Here you can read about it.
I have a similar class.
It's one of the most fun part to me work with matrix 3D.
Well, let's to the answer.
I'm working with OpenGL ES, so to me performance is a crucial part. I make a routine, test it, test it, stress tests, rebuild whole routine and test, test... until to find the best way to save memory and increase performance.
So, thinking in maximum performance, and if you, like me, have a class to work with matrices, I tell you that the best way to get it is:
• Store the rotation's values in variables before put it in the matrix.
At this way you don't need to perform complex Euler calculations at every time that you want to get these values. The same is true for the scale's values. Just the translations that have separated indexes don't need this.