Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Baemz

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Baemz

    Synchronization in DX12

    Apparently I seem to have fixed the issue. Initially I was creating both my CPU event and my GPU event at creation of my waitable-class. I used a reset-function to reset the event and increment my fence. Lastly in the reset I did a call to SetEventOnCompletion. Somehow when trying to use ResetEvent on this event it got out of sync with my waits and the event remained in signaled-mode forever. The thing I do now is whenever a call is made to wait for the GPU. I look if the current fence value is lower than the completed value, and if so, I create a temp-event, call SetEventOnCompletion with that event and the fence values, then wait for the event. This path worked fine for me and now it's running smooth. Thanks to @SoldierOfLight for taking time to answer my questions.
  2. Baemz

    Synchronization in DX12

    I'm using the CommandQueue::Wait for GPU waits and SetEventOnCompletion to bind the fence to a handle for later use with WaitForSingleObject. For CPU I'm simply using Windows Events, eg SetEvent & ResetEvent, together with WaitForSingleObject. The one thing that have come to my mind is whether or not it is okay to call several Signals on the Cmdqueue inbetween Executes. I know I read somewhere that you shouldn't expect a signal to be triggered more than once per Execute, but I'm not sure in what context that was.
  3. Hello, I am working on a DX12 renderer which is utilizing multiple threads to build command lists. I am currently trying to figure out a proper way to handle fencing and synchronization between the threads. My problem is that for some reason my waits seem to be passing through even if the fence hasn't yet been signaled. This is my structure: Render Thread: Supplies render data from scene and launches several render tasks on worker threads. Lastly uses GPU&CPU waits to check if all tasks are ready before executing Present. Worker threads: Builds command list for specified task. Uses cpu-waits if there are dependencies. Queues itself into Queue-thread for GPU-submission. Queue-thread: Runs continously, checking if any cmd list has been queued. Inserts gpu-waits if needed. Executes the cmd list and lastly signals fence. As noted, the fences seem to act as if they are signaled when Render thread reaches present. Am I missing something trivial? /Baemz
  4. Hello To start of this topic I want to introduce myself so that you get an idea of who I am and what my ambitions for this project are. My name is Hampus, I currently work at Massive Entertainment (Ubisoft) as a Graphics Programmer. I've been into programming for almost 8 years now and I have a degree from the education The Game Assembly under my belt. Since about 3 year back I've been programming a "hobby" engine, from scratch, at home just so that I had a platform to test technologies & to learn new things. As my knowledge improved and new technologies was discovered I felt more and more attracted to the idea of developing a "real" engine from scratch. An engine that is build truly for next-gen and cutting edge technologies. The project would be open-source, sharing knowledge to the industry, and of course free to use for developers wanting to try it (atleast as a starting-point). In fact I became so attached to this idea that I actually left all my work on the hobby engine and started setting up a new solution for a "real" engine. This was in the beginning of summer 2018. As of now the engine is actually running a stable first iteration of DX12 with working scalable threading and the structure is getting there. Think this sounds a bit interesting yet? Have a look at my (Git Repository)! Now the reason that I start this topic is because I simply don't have the time to develop this all on my own. I would want some more people to join me to work on this engine together, bringing it to new heights, and hopefully spread knowledge through the industry. So what is it actually that I am looking for? Engine Programmers - I need a few fellow programmers that can help me structure the engine and help me build the low-end foundation. As a programmer you should be confident working with low-level systems and backend engine features such as Rendering, Physics, I/O-management etc. You should have understanding of how a game-engine works and how to design future-proof systems. Experience with threading is also a very big plus. Performance is key in game-engines, therefore you should be confident with profiling and debugging of your code. Technical Artists - I would love to have some tech art aboard aswell for experimenting with shaders, graphical features, performance and tools. You should be confident in common shader languages (HLSL, GLSL etc). You should have good knowledge of how the graphics pipeline works. Artists - Since the engine is not up an running full yet, and there isn't a great pipeline for assets, there's not a great need of artists yet. However, if there is any artist out there who would love to be a part of this journey, I will gladly consider it. There's always a need for art to test with and build environments to test graphical features. You should be confident in working with any industry-standard modeling program (Maya, 3Ds, Blender) and have a rough knowledge of how a typical asset pipeline works. You should also be confident working with PBR materials. General guidelines - If you consider joining, I will require a few things from you. You have to follow the coding standard! There will be a strict submit review before any submits go live in the main branch. Take it seriously, be proud of your work. Have fun, share your knowledge, share this project, have a chat with the other team-members. Do NOT under any circumstances do anything illegal with this software. (like selling it or copy others work into ours without permission etc.) PS! There's still some work that I need to go through on the engine and the documents that comes with it, therefore it might be a bit confusing and the code might be a bit broken at the moment, but I still wanted to put up this ad to see if there's even any interest. Best regards, Hampus
  5. Hello, I've been working on some culling-techniques for a project. We've built our own engine so pretty much everything is built from scratch. I've set up a frustum with the following code, assuming that the FOV is 90 degrees. float angle = CU::ToRadians(45.f); Plane<float> nearPlane(Vector3<float>(0, 0, aNear), Vector3<float>(0, 0, -1)); Plane<float> farPlane(Vector3<float>(0, 0, aFar), Vector3<float>(0, 0, 1)); Plane<float> right(Vector3<float>(0, 0, 0), Vector3<float>(angle, 0, -angle)); Plane<float> left(Vector3<float>(0, 0, 0), Vector3<float>(-angle, 0, -angle)); Plane<float> up(Vector3<float>(0, 0, 0), Vector3<float>(0, angle, -angle)); Plane<float> down(Vector3<float>(0, 0, 0), Vector3<float>(0, -angle, -angle)); myVolume.AddPlane(nearPlane); myVolume.AddPlane(farPlane); myVolume.AddPlane(right); myVolume.AddPlane(left); myVolume.AddPlane(up); myVolume.AddPlane(down); When checking the intersections I am using a BoundingSphere of my models, which is calculated by taking the average position of all vertices and then choosing the furthest distance to a vertex for radius. The actual intersection test looks like this, where the "myFrustum90" is the actual frustum described above. The orientationInverse is the viewMatrix in this case. bool CFrustum::Intersects(const SFrustumCollider& aCollider) { CU::Vector4<float> position = CU::Vector4<float>(aCollider.myCenter.x, aCollider.myCenter.y, aCollider.myCenter.z, 1.f) * myOrientationInverse; return myFrustum90.Inside({ position.x, position.y, position.z }, aCollider.myRadius); } The Inside() function looks like this. template <typename T> bool PlaneVolume<T>::Inside(Vector3<T> aPosition, T aRadius) const { for (unsigned short i = 0; i < myPlaneList.size(); ++i) { if (myPlaneList.ClassifySpherePlane(aPosition, aRadius) > 0) { return false; } } return true; } And this is the ClassifySpherePlane() function. (The plane is defined as a Vector4 called myABCD, where ABC is the normal) template <typename T> inline int Plane<T>::ClassifySpherePlane(Vector3<T> aSpherePosition, float aSphereRadius) const { float distance = (aSpherePosition.Dot(myNormal)) - myABCD.w; // completely on the front side if (distance >= aSphereRadius) { return 1; } // completely on the backside (aka "inside") if (distance <= -aSphereRadius) { return -1; } //sphere intersects the plane return 0; } Please bare in mind that this code is not optimized nor well-written by any means. I am just looking to get it working. The result of this culling is that the models seem to be culled a bit "too early", so that the culling is visible and the models pops away. How do I get the culling to work properly? I have tried different techniques but haven't gotten any of them to work. If you need more code or explanations feel free to ask for it. Thanks.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!