In ERD I am used to see something like:
But I ran into some cases where the triangle is upsidedown, like:
So I wondered, does the direction of the ISA triangle matters? It seems only logical that the pointy vertex would point at the parent, and inheritants would go from the edge itself.
There's no inherent meaning in the orientation of the triangle. In your examples, they mean exactly the same thing. Different tools might implement it differently, and there are other conventions for subtyping besides triangles.
I suggest you pick the more popular convention and stick with it.
Related
I've been looking for a robust method of pathfinding for a platformer based game I'm developing and A* looks like it's the best method available. I noticed there is a demo for the AStar implementation in Godot. However, it is written for a grid/tile based game and I'm having trouble adapting that to a platformer where the Y axis is limited by gravity.
I found a really good answer that describes how A* can be applied to platformers in Unity. My question is... Is it possible to use AStar in Godot to achieve the same thing described in the above answer? Is it possible this could be done better without using the built in AStar framework? What is a really simple example of how it would work (with or without AStar) in GDscript?
Though I have already posted a 100 point bounty (and it has expired), I would still be willing to post another 100 point bounty and award it, pending an answer to this question.
you could repurpose the Navigation2D node for platformer purposes. The picture below shows an example usage. The Navigation2D node makes it possible to navigate the shortest path between two point that lie within the combined navigation polygon (this is the union of all NavigationPolygonInstances).
You can use the get_simple_path method to get a vector2 array that describes the points your agent/character should try to reach (or get close to, by using some predefined margin) in sequence. Place each point in a queue, and move the character towards the different points by moving it horizontally. Whenever your agent's next point in the queue is too high up to reach, then you can make the agent jump.
I hope this makes sense!
The grey/dark-blue rectangles are platforms with collision whereas the green shapes are NavigationPolygonInstance nodes
This approach is by no means perfect. If you were to implement slopes into your game then the agent may jump up the slope instead of ascending it normally. It is also pretty tedious to create all the shapes needed.
A more robust solution would be to have a custom graph system that you could place in the scene and position its vertices. This opens up the possibility to make one-way paths and have certain edges/connections between vertices marked as "jumpable" only. This is a lot more work though if you can not find any such solution online.
https://www.dropbox.com/s/phven3rriv36893/graphicsview-pathitem.png?dl=0
I wonder if there's a way to make my QGraphicsPathItem respond to mouseHoverEvents to the actual curve instead of the whole orange area as seen in the docs.
https://www.dropbox.com/s/7m8w34nitp34sgf/pipes.png?dl=0
In my application I'm not seeing the area that actually forms the path and therefor I only want a hoverEnterEvent when the bezier curve is hovered (and a hoverLeaveEvent when the bezier is left of, course).
Is that possible to achieve with QGraphicsPathItem or is that a completely wrong approach? If yes, how? If not, what QGraphics object can be considered as a replacement?
If code is really needed, let me know.
Cheers,
Michael
Tim Wakeham's answer is totally correct: you need to re-implement shape() to provide a more detailed shape for your path item. However, his answer is not totally useful, since it's not trivial to implement a good shape() method returning the right QPainterPath.
It's even more confusing because in this case, the QGraphicsPathItem can already provide a QPainterPath from its path() method. Unfortunately that is generally not the right value to return from the shape() method since it draws the item rather than delimits its outside.
Fortunately, since this is a fairly standard requirement, there is a built-in class to transform the path into an outline that can be used for the shape: QPainterPathStroker.
Here's some code I use to do that:
qp = QtGui.QPainterPathStroker()
qp.setWidth(MARGIN)
qp.setCapStyle(QtCore.Qt.SquareCap)
shape = qp.createStroke(self.path())
You need to reimplement QGraphicsItem.shape to return a more accurate representation of your curve. The default implementation gives you the bounding box as you've discovered.
I'm a (theoretical) computer science student, and as such the investigating of semantics of programming languages is one of the subjects of my study (wikipedia).
I've played around a lot with CSS and have a reasonable understanding of the box positioning rules. (If you tell me to create a page with certain layout, I can often think of the correct box approach and applicable CSS rules.)
It would be cool to have some sort of formal semantics for the CSS box positioning rules, but after searching the net for a while, I couldn't quite find anything useful.
I mostly simply end up at the CSS specifications, which are formatted as long texts with pseudo-algorithms (not the greatest reading matter --- I haven't read any of these specifications with much effort just yet).
Has no one tried to formalize this “theory” into some mathematical model, more rigorous than what the specifications have to offer? I'm not looking for something complete or definitive, but it sure would be neat (and useful!) if, at least, the way boxes should be positioned could be modeled in a formal manner.
Does anyone know of such research?
Not an answer! This is an example of a possible formalization of a very simplified case (see my comment above).
Say, for instance, we're working in a world featuring (1) a known screen width , (2) an ordered list of boxes which aren't nested, have no margins/padding's/borders, are floated left and of which we know their (2.1) height and (2.2) width via the mathematical functions and .
We'll be defining the functions and , which state the coordinates of the left upper corner of each box.
We'll be defining/using the relations " starts line " and " has height ".
First of all, starts line 0.
Then, if starts line , and furthermore if for certain
...we conclude that:
has height
starts line +1 iff
These rules define the positions of given boxes in a formal manner. It's only one way to do so, of course, and probably not the smartest (just thought it up quickly), but it does correctly formalize the way floats work (modulo typos, I haven't checked it over well enough).
When dealing with programming languages, one can choose of many of these formalisms, each invented for particular purposes (see wikipedia).
I'm just interested if anyone has ever tried to come up with some formalization for CSS box positioning. Of course the specifications go a long way, but they're just not quite as rigorous as the mathematical way forces you to be.
Does anyone have any good implementation strategies or resources for putting together a b-rep modeling system?
OpenCascade is an apparently good library for b-rep modeling (used by FreeCad and PythonOCC are both very cool) but the library is huge, complicated and may not be a good starting point to learn about b-rep modeling 'engines'.
I've done quite a bit of research paper reading, and while the fundamental math is useful for understanding why everything works, its left me with some implementation questions.
The halfedge data-structure seems to be the preferred way to store information about a body in b-rep implementations.
So a handful of questions in no particular order:
Using the halfedge data-structure how is rendering typically implemented? Triangulation based on the solid's boundaries?
How are circular faces/curved surfaces typically implemented? For instance a cylinder in one basic introduction to b-rep's I read, was internally stored as a prism. IE an extruded triangle and meta-data was stored about the cap faces denoting that they were indeed circular.
How are boolean operations typically implemented? I've read about generating BSP-Tree's along the intersection curves then combining those tree's to generate the new geometry. Are there other ways to implement boolean operations and what sort of pro's/con's do they have?
Thanks!
If you'd like to provide a code example don't worry about the language -- the questions are more about algorithmic/data-structure implementation details
I'm working on a B-Rep modeler in C# (I'm in a very early stage: it's an huge project) so I ask myself the same questions as you. Here is my answers:
Triangulation: I've not done this step, but the strategy I'm thinking about is as follow: project the face boundaries in parameter space to obtain 2D polygons (with holes), triangulate that with the ear clipping algorithm and then reproject triangle vertices in 3D space. For curved surfaces, I need to split the polygons with a grid in order to follow the surface;
For a cylinder, there is 3 edges : two circulars and one line segment. I have classes for each type of curves (Segment3d, Circle3d...) and each half-edge hold an instance of one of theses classes. Each face hold an instance of a surface object (plane, cylinder, sphere...);
There is an interesting project here based on BSP-Tree, but it uses CSG method, not B-rep. I'm still researching how to do this, but I don't think I will need a BSP tree. The difficulty is in computing intersections and topology.
The best books I've found on this subject:
3D CAD - Principles and Applications (old but still relevant)
Geometric Modeling: The mathematics of shapes (more recent than the previous one, but less clear)
Whats the best way to detect collisions in a 2d game sprites? I am currently working in allegro and G++
There are a plethora of ways to detect collision detection. The methods you use will be slightly altered if depending on if your using a 2d or 3d environment. Also remember when instituting a collision detection system, to take into account any physics you may want to implement in the game (needed for most descent 3d games) in order to enhance the reality of it.
The short version is to use bounding boxes. Or in other words, make each entity in the world a box, then check if each of the axises of the box are colliding with other entities.
With large amounts of entities to test for collisions you may want to check into an octree. You would simple divide the world into sectors, then only check for collision between objects in the same sectors.
For more resources, you can go to sourceforge and search for the Bullet dynamics engine which is an open source collision detection and physics engine, or you could check out http://www.gamedev.net which has plenty of resources on copious game development topics.
Any decent 2D graphics library will either provide its own collision detection functions for everything from aligned sprites to polygons to pixels, or have one or more good third party libraries to perform those functions. Your choice of engine/library/framework should dictate your collision detection choices, as they are likely far more optimized than what you could produce alone.
For Allegro there is Collegro. For SDL there is SDL_Collide.h or SDL-Collide. You can use I_COLLIDE with OpenGL. DarkBASIC has a built in collision system, and DarkPhysics for very accurate interactions including collisions.
Use a library, I recommend Box2D
This question is pretty general. There are many ways to go about collision detection in a 2d game. It would help to know what you are trying to do.
As a starting point though, there are pretty simple methods that allow for detection between circles, rectangles, etc. I'm not a huge fan of gamedev.net, but there are some good resources there about this type of detection. One such article is here. It covers some basic material that might help you get started.
Basic 2d games can use rectangles or circles to "enclose" an object on the screen. Detection of when rectangles overlap or when circles overlap is fairly straightfoward math. If you need something more complicated (such as convex artibrary polys), then the solution is more complicated. Again, gamedev.net might be of some help here.
But really to answer your question, we need to know what you are trying to do? What type of game? What type of objects are you trying to collide? Are you trying to collide with screen boundaries, etc.
Checking for collision between two balls in 2D is easy. You can google it but basically you check if the length of the two balls radius combined is larger or equal to the distance between the center of the two balls.
Then you can find the collision point by taking the unit vector between the center of the balls and multiply it with one of the balls radius.
Implementation of a collision detection system is a complicated matter, but you want to consider three points.
World of objects. Space Partitioning.
If you do a collision check against every 2d sprite in your world against everything else, you'll have a slow slow program! You need to prioritize. You need to partition the space. You can use an orthogonal grid system and slice your world up into a 2d grid. Or you could use a BSP tree, using lines as the seperator function.
Broad phase collision detection
This uses bounding volumes such as cylinders or elipses (whichever approximates the shape of your sprites the best) to determine whether or not objects are worth comparing in more detail. The math for this is easy. Learn your 2d matrix transformations. And for 2d intersection, you can even use high powered video cards to do a lot of the work!
Narrow phase collision detection
Now that you've determined that two or more objects are worth comparing, you step into your fine tuned section. The goal of this phase is to determine the collision result. Penetration depth, volume encompassed, etc... And this information will be fed into whatever physics engine you got planned. In 3d this is the realm of GJK distance algs and other neato algorithms that we all love so much!
You can implement all of this generically and specify the broad and narrow resolutions polymorphically, or provide a hook if you're working in a lower level language.
Collisions between what? It depends whether you use sprites, concave polygons, convex polygons, rectangles, squares, circles, points...