Jump to content

  • Log In with Google      Sign In   
  • Create Account

GuyWithBeard

Member Since 04 May 2006
Offline Last Active Jun 23 2016 05:34 AM

Posts I've Made

In Topic: Problems with "stickiness"

22 June 2016 - 06:42 AM

Can you not have high-poly objects for rendering and lower-poly physics spheres if the physics geometry is what is driving your "stickiness"...?


In Topic: How to render my DirectX C++ Engine to a C# Panel

21 June 2016 - 08:22 AM

What exactly are you trying to do? Use a c++ renderer in a c# application? If so, passing the HWND to the renderer is just one of many many things that you need to implement, so us doing that one thing for you won't get you very far. What seems to be the problem with handing the window handle to the c++ side?

 

FWIW, my editor which is a C# application does this to pass the handle to my C++ renderer, which in my case is in another process so I use the network rather than a C++/CLI wrapper to do the communication, but since the value is an integer you should have no problem sending that across the language border.

public void InitRenderWindow()
{
    if (EditorApp.Instance.IsConnectedToGame)
    {
        IntPtr handle = m_renderPanel.Handle;
        EditorApp.Instance.GameRPC.initRenderWindow(handle.ToInt32(), m_renderPanel.Width, m_renderPanel.Height, m_renderPanel.Left, m_renderPanel.Top);
    }
}

But again, if you are having trouble with understanding C++/CLI itself we are not going to do this one thing for you because then you will be stuck on the very next task.


In Topic: Merging groups of entities into convex hulls

16 June 2016 - 01:50 AM

One more thing I am considering adding to the above algorithm is a check that the combined convex hull has the same number of points as the individual shapes. In practice this will always be 4 since we are dealing with boxes. This should eliminate the potential problem case where two boxes are close to each other and one is slightly rotated around the world up axis but the CH area still happens to match the individual shapes' areas. In this case we would not want to merge the boxes since the the resulting convex hull would not match the outline of the individual boxes.

 

This has not happened to me yet, but I assume it could, given the right circumstances.


In Topic: Merging groups of entities into convex hulls

15 June 2016 - 03:12 PM

I made a little progress.

 

In my system horizontal merging is a lot more important than vertical because the visibility system is essentially 2D. Every object has an upper and a lower bound so they can be included/excluded in the visibility calculations as the observer moves up and down, but the construction of the line-of-sight geometry is all done in the X-Z-plane (Y is up in my engine).

 

So I came up with this algorithm (dunno if this is an established way of doing things, but it is working fine for me):

  • Get a list of objects that we consider for merging, called the "main list" below
  • Pick the first object in the list, called "reference box", or "ref box" below
  • Check if the shape of the object is a box, if not we cannot merge it so just submit it as-is
  • If the shape is a box, we will try to merge it with other boxes
  • Get a new list, called the "merge list" containing all objects except the ref box
  • Iterate over all objects in the list and process those that are boxes, sorted by distance to the ref box (closest first)
  • For each box, check if the upper and lower bounds are the same as the ref box, if not then we cannot merge
  • If the bounds match the ref box, calculate 2D convex hulls for both shapes in the X-Z-plane, then calculate the areas of the convex hulls
  • Calculate the convex hull of the combined shape, then calculate the area of that convex hull
  • Check if the sum of the original areas of the convex hulls roughly equal the new combined area
  • If the areas are equal, we can merge the boxes together
  • Continue with the rest of the objects in the merge list, attempting to merge each with with the ever-growing ref box
  • Remove all processed objects from the main list

Using this technique I managed to nicely merge most of the geometry in my test level. Check out the picture below:

 

merging.png

 

The colored boxes represent box objects. The colors are selected from a list of a few colors and sometimes the same color appears on adjacent objects. From the image you can see that the algoritm works with both world space axis aligned objects as well as rotated ones. You can also see (on the wall of boxes in the lower left corner) that the algorithm does not merge objects vertically.

 

In the test level above the number of objects decreased from 266 to 45.

 

Fun!


In Topic: Merging groups of entities into convex hulls

14 June 2016 - 11:24 PM

Yeah, I might have to implement something brute-force unless I can come up with a more elegant solution. The shapes aren't necessary AABBs. In the above screenshot they are but I have cases where the whole row of boxes would be rotated say 10 degrees around the world up axis.

 

What I forgot to mention is that the algorithm does not need to be particularily fast as I am planning to do the merging on the editor side and only when manually starting it. Also, for my current needs I would be ok with merging only box shapes of equal size as that is the majority of the level geometry.

 

As for the performance gains, they are huge with proper merging. The physics engine handles individual shapes quite well but I am using the physics shapes as input into a visibility system for AI characters which slows down considerably with these small individual shapes.


PARTNERS