I am trying to perform my own logic for hit testing and have dynamic Y Axis that exist within my lightningchart JS charts. At the moment I am off by the amount of pixels that the axis is taking up, but have not found a way to determine this value.
Axis documentation shows the use of Axis.getHeight() which returns the height in pixels for the X Axis.
Is there a way to set/read the width of Y Axis in LightningCharts JS?
Thanks
Edit: As requested for more information.
I am using pointer down/move/end/out to detect finger/pointer/mouse position over the charts.
This particular chart presents for example the following data
[x: 0, y: 20]
[x: 3600, y: 21]
[x: 86400, y: 19]
Where x is time in seconds and y is temperature in Celsius.
This will be represented as a lineseries for visual but also a point series for interaction. Users will be able to drag the points up/down based on an interval of say 0.5C and left/right based on a time interval of say 600 (5 minutes).
On tablet, this interaction must be performed by first tapping on the point (to activate it, and present a tooltip) and then dragging the point. This is to prevent conflict with panning/zooming the chart.
All of the above has been developed and is working for the exception of when the YAxes are visible and impact the chart spacing.
I need a way to calculate very specifically the width of all yAxes collectively to support the manual hit testing logic.
Could you elaborate what kind of hit testing you are doing? It is possible that there is a better way to do it than something based on Axis height, hence I am asking.
The getHeight() method is available for both X and Y axis. To use it for Y axis, just do chart.getDefaultAxisY().getHeight(). However, this method is a bit unreliable - the result can be a frame behind. For example, if you use it immediately when the chart is created, it might return a wrong value. A possible workaround is to use it after a timeout.
Another way to know for sure the width of Y axis is to explicitly configure it yourself with Axis.setThickness(100). This would make the Axis 100 pixels wide always.
Related
I have an problem: My 3d plot gets distorted, if I rotate or pan the plot. I know this behaviour is intended to show the user the most at all times, but it looks silly, so I want an orthogonal view or Axes which are equally long.
Earth distorted.
I have an WPF Application, where the ILN Form/Control is hosted via WindowsFormsHost.
I tried every possibility regarding Plotcube.Projection, have set Plotcube.Limits, changed ILN_Panel autosize etc. My next idea was that maybe I need to configure the WPF and/or Forms window itself.
Thanks!
I think that is not possible. At least not easy within PlotCube. If you do not need PlotCube just put the object into the Camera node and set Projection to Orthogonal. And you are done.
With PlotCube it is much more complicated. You must make sure that all containers have equal aspect ratio (width / height) WinformsHostControl, PlotCube, PlotCube.ScreenRect, PlotCube.DataScreenRect, PlotCube.Plots (data group), and its Limits. If you want to rotate everything free you must make sure to have equal aspect ration on all 3 dimensions wehere applicable.
Some of the folks on my team, including myself, find it pretty disorienting that in a Bokeh scatter plot, say using the circle method, that for an initial autoscale fit of the data on the figure we can dial in a reasonable size for our data, using for example something like plot.circle( x , y , size=3 )
However when we interactively zoom into our data the glyph sizes as displayed are invariant to the zoom. Is there a way to have them scale proportionally to the zoom we've dialed into? Something akin to an vector graphics interaction (eg svg). If memory serves me right matlab figures and matplotlib figures should maintain zoom proportionality behavior. To demonstrate the behavior we're seeing consider the first image and the red box I approximately zoom into on the second image.
Just as a quick demo using Powerpoint to illustrate the sort of desired behavior...
For circles, set the radius kwarg instead of the size value. (There similar, glyph-specific values for the other glyph-types).
i.e.:
plot.circle(x=[1,2,3], y=[1,2,3], radius=0.5)
size is always rendered in screen coordinates (pixels), but radius and the related properties are computed in data coordinates and should change in magnitude with zooming.
Here's a good demo by Bryan Van de Ven showing the difference between pixel coordinates (size) and data coordinates (radius) given in this conference talk:
Intro to Data Visualization with Bokeh - Part 2 - Strata Hadoop San Jose 2016
... the point is all of these attributes can be vectorized. We could
for instance say size equals you know 2, 4, 6, 8, 10, and now the size
is modulated right. So we have one that has size 2 and one that has
size 4. Size is usually in pixels, radius is usually in data dimension
units. But all the other ones here as well all the colors, all the
visual attributes can be vectorized in this way. You can either give
them a single value as we've done for instance with the line fill
color, or you can give them a vector of values in which case all of
the things are different.
So next exercise here you go to this
notebook this is that second notebook "02 - plotting" it is to try to
create the same example but now set the radius instead of the size and
sort of see what's the difference if you set if you set radius instead
of size.
I am trying to enlarge a point cloud data set. Suppose I have a point cloud data set consisting of 100 points & I want to enlarge it to say 5 times. Actually I am studying some specific structure which is very small, so I want to zoom in & do some computations. I want something like imresize() in Matlab.
Is there any function to do this? What does resize() function do in PCL? Any idea about how can I do it?
Why would you need this? Points are just numbers, regardless whether they are 1 or 100, until all of them are on the same scale and in the same coordinate system. Their size on the screen is just a visual representation, you can zoom in and out as you wish.
You want them to be a thousandth of their original value (eg. millimeters -> meters change)? Divide them by 1000.
You want them spread out in a 5 times larger space in that particular coordinate system? Multiply their coordinates with 5. But even so, their visual representations will look exactly the same on the screen. The data remains basically the same, they will not be resized per se, they numeric representation will change a bit. It is the simplest affine transform, just a single multiplication.
You want to have finer or coarser resolution of your numeric representation? Or have different range? Change your data type accordingly.
That is, if you deal with a single set.
If you deal with different sets, say, recorded with different kinds of sensors and the numeric representations differ a bit (there are angles between the coordinate systems, mm vs cm scale, etc.) you just have to find the transformation from one coordinate system to the other one and apply it to the first one.
Since you want to increase the number of points while preserving shape/structure of the cloud, I think you want to do something like 'upsampling'.
Here is another SO question on this.
The PCL offers a class for bilateral upsampling.
And as always google gives you a lot of hints on this topic.
Beside (what Ziker mentioned) increasing allocated memory (that's not what you want, right?) or zooming in in visualization you could just rescale your point cloud.
This can be done by multiplying each points dimensions with a constant factor or using an affine transformation. So you can e.g switch from mm to m.
If i understand your question correctly
If you have defined your cloud like this
pcl::PointCloud<pcl::PointXYZ>::Ptr cloud (new pcl::PointCloud<pcl::PointXYZ>);
in fact you can do resize
cloud->points.resize (cloud->width * cloud->height);
Note that doing resize does nothing more than allocate more memory for variable thus after resizing original data remain in cloud. So if you want to have empty resized cloud dont forget to add cloud->clear();
If you just want zoom some pcd for visual puposes(i.e you cant see what is shape of cloud because its too small) why dont you use PCL Visualization and zoom by scrolling up/down
I've written some code which lets an arbitrary sized rectangle collide with a grid-based terrain setup (for a platformer game). The way I do it is something like this:
For each tile the rectangle intersects with, do:
Calculate the primary axis that this tile is on with respect to the rectangle
Calculate the interpenetration of this tile into the rectangle along the primary axis (factoring in previous position offsets from other tiles)
If this tile is solid, add that interpenetration to a total collision resolution vector
Adjust the rectangle's position by the total calculated collision resolution vector
Which works just fine, except i run into random "hang-ups" as my rectangle gets pulled into the ground just over the border of two tiles, my code decides that it needs to resolve the collision with this new tile by pushing it in the X axis, thus stopping the rectangle's motion unless it is manually pushed out of the terrain to get over it.
I've tried only resolving the collision on one axis at a time (so it ignores any x axis collision resolution if the Y axis resolution is the largest and vice versa), but that results in jittering when the rectangle is being pressed into a corner (as this is a situation that actually needs both axes resolved at once).
In short, what method can I use to fix both of these problems at once?
This is very hard problem because it has infinity interactions in some cases.
To choose between speed and accuracy:
1.add interaction counter for every object (rectangle)
before collision detection reset all counters to zero
2.if any collision detected increment counters for all objects in collision
3.if counter value exceeds limit value stop computation of interaction for that object
Beware that this approach can also create some hiccups if forced to but will not hang up.
I'm making a side scroller similar to Castle Crashers and right now I'm using SAT for collision detection. That works great, but I want to simulate level "depth" by allowing objects to move up and down on the screen, basically along a z-axis (like this screenshot http://favoniangamers.files.wordpress.com/2009/07/castle-crashers-ps3.jpg). This isn't an isometric game, but rather uses parallax scrolling.
I added a z component to my vector class, and I plan to cull collisions based on the 'thickness' of a shape and it's z position. I'm just not sure how calculate the positions of shapes for rendering or how to add jumping with gravity. How do I calculate the max y value (for the ground) as the z position changes? Basically it's the relationship of the z and y axis that confuses me.
I'd appreciate links to resources if anyone knows of this topic.
Thanks!
It's actually possible to make your collision detection algorithm dimensionally agnostic. Just have a collision detector that works along one dimension, use that to check each dimension, and your answer to "are these colliding or not" is the logical AND of the collision detection along each of the dimensions.
Your game should be organised to keep the interaction of game objects, and the rendering of the game to the screen completely seperate. You can think of these two sections of the program as the "model" and the "view". In the model, you have a full 3D world, with 3 axes. You can't go halvesies on this point without some level of pain. Your model must be proper 3D.
The view will read the location of all the game objects, and project them onto the screen using the camera definition. For this part you don't need a full 3D rendering engine. The correct technical term for the perspective you're talking about is "oblique", and it can be seen in many ancient chinese and japanese scroll paintings and prints- in particular look for images of "The Tale of Genji".
The on screen position of an object (including the ground surface!) goes something like this:
DEPTH_RATIO=0.5;
view_x=model_x-model_z*DEPTH_RATIO-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;
you can modify for a straight orthographic front projection:
DEPTH_RATIO=0.5;
view_x=model_x-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;
And of course don't forget to cull objects outside the volume defined by the camera.
You can also use this mechanism to handle the positioning of parallax layers for you. This is of course, a matter changing your camera to a 1-point perspective projection instead of an orthographic projection. You don't have to use this to change the rendered size of your sprites, but it will help you manage the x position of objects realistically. if you're up for a challenge, you could even mix projections- use 1 point perspective for deep backgrounds, and the orthographic stuff for the foreground.
You should separate your conceptual Y axis used by you physics calculation (collision detection etc.) and the Y axis you actually draw on the screen. That way it becomes less confusing.
Just do calculations per normal pretending there is no relationship between Y and Z axis then when you actually draw the object on the screen you simulate the Z axis using the Y axis:
screen_Y = Y + Z/some_fudge_factor;
Actually, this is how real 3d engines work. After all the world calculations are done the X, Y and Z coordinates are mapped onto screen_X and screen_Y via a function (usually a bit more complicated than the equation above, but just a bit).
For example, to implement pseudo-isormetric view in your game you can even apply Z to the screen_X axis so objects are displaced diagonally instead of vertically.