Tag Info

New answers tagged

0

I think you should break this up into multiple questions and try again. Offhand, I see 3 questions that all warrant their own detailed answers, but there are probably more that you can ask to get the detailed answers you wish for: Using 3D to generate 2D Sprites You can just use 3D as a way to render Sprites, i.e. by creating your animations, then ...


0

The idea of phsically based rendering is to reach a closer approximation of how light behaves in the real world and use this model to generate a 2d impression of a 3d scene. This is basically what we are doing since the invention of 3d graphics, just with more simplified models of optics. So yes, PBR is mostly a buzzword. A perfect approximation of ...


1

Physcially-Based Rendering (PBR) is really a modern tag people use to refer to the trend of making the rendering system "correct" with regard to the real-world physics of light interacting with surfaces, rather than an exact definition of a full rendering system. In other words, I would say PBR is more a definition of the aspiration of the system than what ...


0

Construct a new projection matrix, with smaller FOV and near/far planes shifted towards the middle. Then build your shrinked Frustum out of it - simple as that.


2

I think the approach you are probably looking for is to trigger damage based on some event, which is keyed to a particular time or frame in the animation. I'm not sure exactly how you can set this up in your case as I'm not familiar with the specific tools etc. but the general concept would be: For each attack animation, define at which frame / time offset ...


0

I can see several issues: You should probably deal the damage at the end of the animation. That way, if the damage causes the opponent to die, the animation is done and doesn't keep waving the sword over a dead body. If you can, break your animation up into several steps and deal the damage in several smaller increments, and just stop dishing out damage ...


2

In theory, it will take the same time to render regardless. However, if a point occluded points in the back, then some pixels may be discarded before they are rasterized (because they failed the depth test), and I can imagine that that would be slightly faster.


0

There are many ways to perform collision detection Cello Coder. The simplest may not be the best solution for your game and may cause bugs to show up... I have never used LWJGL so there might be a library someone has made for collisions, but it really comes down to two ways. easy way - buggy - perform a check to see if the mesh of object one is near ...


0

This function takes in mouse coordinates and picks the model from the 3d scene by shooting a ray through it. Btw the screen size in world coordinates is 2x2 stretching from -1 to +1 on both the x and y axis. The screen size in pixels would be mClientWidth and mClientHeight. You'll see both those in "Compute picking ray in view space" void Pick(int sx, int ...


1

It appears that you are trying to write a 3D render engine, and you want the faces to be rendered from front to back so you don't get an x-ray effect. Your current method would not work with intersecting faces. Z-Buffering A Z-buffer is an array that stores the z-distance of every pixel in the viewport: Image from Wikipedia: Original page. When you ...


0

Edit: This compiles (C#): void createVertexBuffer<T>() where T : struct, IVertexType { List<T> vertexList = new List<T>(); VertexBuffer vb = new VertexBuffer(OpenCityComponent.GraphicsDevice, typeof(T), 10, BufferUsage.None); vb.SetData(vertexList.ToArray()); } To move List<T> into the class, I'd have to move <T> to the ...


0

Most of your efficiency benefit can come from checking against a loose bound for your whole shape (box or sphere known to contain it). When you find that the ray "might" intersect it (because it intersects a sphere or box that's not much larger), then you pretty much need to check each face. You can skip faces whose normals point away from the ray, since a ...


1

You need to set the blendstate to alpha blending when rendering your objects. You can do it like this: GraphicsDevice.BlendState = BlendState.AlphaBlend; This piece of code should go before drawing your mesh.


9

Actually A* does not use dimensions. A* works with nodes and each nodes have paths to other nodes. In the case of a 2D grid every cell is a node and every boundary is an implicit path (left, right, up, down, and/or diagonals), the key here is that it is implicit. This is a trick to reduce the memory footprint, but A* itself does not require a 2D or 3D ...



Top 50 recent answers are included