• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By racarate
      Hey everybody!
      I am trying to replicate all these cool on-screen debug visuals I see in all the SIGGRAPH and GDC talks, but I really don't know where to start.  The only resource I know of is almost 16 years old:
      http://number-none.com/product/Interactive Profiling, Part 1/index.html
      Does anybody have a more up-to-date reference?  Do people use minimal UI libraries like Dear ImgGui?  Also, If I am profiling OpenGL ES 3.0 (which doesn't have timer queries) is there really anything I can do to measure performance GPU-wise?  Or should I just chart CPU-side frame time?  I feel like this is something people re-invent for every game there has gotta be a tutorial out there... right?
       
       
    • By Achivai
      Hey, I am semi-new to 3d-programming and I've hit a snag. I have one object, let's call it Object A. This object has a long int array of 3d xyz-positions stored in it's vbo as an instanced attribute. I am using these numbers to instance object A a couple of thousand times. So far so good. 
      Now I've hit a point where I want to remove one of these instances of object A while the game is running, but I'm not quite sure how to go about it. At first my thought was to update the instanced attribute of Object A and change the positions to some dummy number that I could catch in the vertex shader and then decide there whether to draw the instance of Object A or not, but I think that would be expensive to do while the game is running, considering that it might have to be done several times every frame in some cases. 
      I'm not sure how to proceed, anyone have any tips?
    • By Vik Bogdanov
       

      As DMarket platform development continues, we would like to share a few case studies regarding the newest functionality on the platform. With these case studies we would like to illuminate our development process, user requirements gathering and analysis, and much more. The first case study we’re going to share is “DMarket Wallet Development”: how, when and why we decided to implement functionality which improved virtual items and DMarket Coins collection and transfer.  
      DMarket cares about every user, no matter how big or small the user group is. And that’s why we recently updated our virtual item purchase rules, bringing a brand new “DMarket Wallet” feature to our users. So let’s take a retrospective look and find out what challenges were brought to the DMarket team within this feature and how these challenges were met. 
      DMarket and Blockchain Virtual Items Trading Rules
      Within the first major release of the DMarket platform, we provided you with a wide range of possibilities and options, assuring Steam account connection within user profile, confirmation of account and device ownership via email for enhanced security, DMarket Coins, and DMarket Tokens exchanging, transactions with intermediaries on blockchain within our very own Blockchain system called “Blockchain Explorer”. 
      And well, regarding Blockchain... While it has totally proved itself as a working solution, we were having some issues with malefactors, as many of you may already know. DMarket specialists conducted an investigation, which resulted in a perfect solution: we found out that a few users created bots to buy our Founder’s Mark, a limited special edition memorabilia to commemorate the launch of the platform, for lower prices and then sell them at higher prices. Sure thing, there was no chance left for regular users. A month ago we fixed the issue, to our great relief. We received real feedback from the community, a real proof-of-concept. The whole DMarket ecosystem turned out to be truly resilient, proving all our detractors wrong. 
      And while we’ve got proof, we also studied how users feel about platform UX since blockchain requires additional efforts when buying or selling an item. With our first release of the Demo platform, we let users sign transactions with a private key from their wallet. In terms of user experience, that practice wasn’t too good. Just think about it: you should enter the private key each time you want to buy or sell something. Every transaction required a lot of actions from the user’s side, which is unacceptable for a great and user-friendly product like ours. That’s why we decided to move from that approach, and create a single unified “wallet” on the DMarket side in order to store all the DMarket Coins and virtual items on our side and let users buy or sell stuff with a few clicks instead of the previous lengthy process. In other words, every user received a public key which serves as a destination address, while private keys were held on the DMarket side in order to avoid transaction signing each time something is traded. This improved usability, and most of our users were satisfied with the update. But not all of them...
      You Can’t Make Everyone Happy….. Can You?
      By removing the transaction signing requirement we made most of our users happy. Of course, within a large number of happy people, we can always find those who are worried about owning a public key wallet. When you don’t own a public key, it may disturb you a little bit. Sure, DMarket is a trusted company, but there are people who can’t trust even themselves sometimes. So what were we gonna do? Ignore them? Roll back to the previous way of buying virtual items and coins? No!
      We decided to go the other way. Within the briefest timeline, the DMarket team decided on providing a completely new feature on Blockchain Explorer — wallet creation functionality. With this functionality, you can create a wallet with 2 clicks, getting both private and public keys and therefore ensuring your items’ and coins’ safety. Basically, we separated wallets on the marketplace and wallets on our Blockchain in order to keep great UX and reassure a small part of users with a needed option to keep everything in a separate wallet. You can go shopping on DMarket with no additional effort of signing every transaction, and at the same time, you are free to transfer all the goods to your very own wallet anytime you feel the need. Isn’t it cool?
      Outcome 
      After implementation of a separate DMarket wallet creation feature, we killed two birds with one stone and made everyone satisfied. Though it wasn’t too easy since we had a very limited amount of time. So if you need it, you can try it. Moreover, the creation of DMarket wallet within Blockchain Explorer will let you manage your wallet even on mobile devices because with downloading private and public keys you also get a 12-word mnemonic phrase to restore your wallet on any mobile device, from smartphone to tablet. Wow, but that’s another story — a story about DMarket Wallet application which has recently become available for Android users in the Google Play.
      Stay tuned for more case studies and don't forget to check out our website and gain firsthand experience with in-game items trading!
    • By fleissi
      Hey guys!

      I'm new here and I recently started developing my own rendering engine. It's open source, based on OpenGL/DirectX and C++.
      The full source code is hosted on github:
      https://github.com/fleissna/flyEngine

      I would appreciate if people with experience in game development / engine desgin could take a look at my source code. I'm looking for honest, constructive criticism on how to improve the engine.
      I'm currently writing my master's thesis in computer science and in the recent year I've gone through all the basics about graphics programming, learned DirectX and OpenGL, read some articles on Nvidia GPU Gems, read books and integrated some of this stuff step by step into the engine.

      I know about the basics, but I feel like there is some missing link that I didn't get yet to merge all those little pieces together.

      Features I have so far:
      - Dynamic shader generation based on material properties
      - Dynamic sorting of meshes to be renderd based on shader and material
      - Rendering large amounts of static meshes
      - Hierarchical culling (detail + view frustum)
      - Limited support for dynamic (i.e. moving) meshes
      - Normal, Parallax and Relief Mapping implementations
      - Wind animations based on vertex displacement
      - A very basic integration of the Bullet physics engine
      - Procedural Grass generation
      - Some post processing effects (Depth of Field, Light Volumes, Screen Space Reflections, God Rays)
      - Caching mechanisms for textures, shaders, materials and meshes

      Features I would like to have:
      - Global illumination methods
      - Scalable physics
      - Occlusion culling
      - A nice procedural terrain generator
      - Scripting
      - Level Editing
      - Sound system
      - Optimization techniques

      Books I have so far:
      - Real-Time Rendering Third Edition
      - 3D Game Programming with DirectX 11
      - Vulkan Cookbook (not started yet)

      I hope you guys can take a look at my source code and if you're really motivated, feel free to contribute :-)
      There are some videos on youtube that demonstrate some of the features:
      Procedural grass on the GPU
      Procedural Terrain Engine
      Quadtree detail and view frustum culling

      The long term goal is to turn this into a commercial game engine. I'm aware that this is a very ambitious goal, but I'm sure it's possible if you work hard for it.

      Bye,

      Phil
    • By tj8146
      I have attached my project in a .zip file if you wish to run it for yourself.
      I am making a simple 2d top-down game and I am trying to run my code to see if my window creation is working and to see if my timer is also working with it. Every time I run it though I get errors. And when I fix those errors, more come, then the same errors keep appearing. I end up just going round in circles.  Is there anyone who could help with this? 
       
      Errors when I build my code:
      1>Renderer.cpp 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2039: 'string': is not a member of 'std' 1>c:\program files (x86)\windows kits\10\include\10.0.16299.0\ucrt\stddef.h(18): note: see declaration of 'std' 1>c:\users\documents\opengl\game\game\renderer.h(15): error C2061: syntax error: identifier 'string' 1>c:\users\documents\opengl\game\game\renderer.cpp(28): error C2511: 'bool Game::Rendering::initialize(int,int,bool,std::string)': overloaded member function not found in 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.h(9): note: see declaration of 'Game::Rendering' 1>c:\users\documents\opengl\game\game\renderer.cpp(35): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(36): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>c:\users\documents\opengl\game\game\renderer.cpp(43): error C2597: illegal reference to non-static member 'Game::Rendering::window' 1>Done building project "Game.vcxproj" -- FAILED. ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========  
       
      Renderer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include "Renderer.h" #include "Timer.h" #include <iostream> namespace Game { GLFWwindow* window; /* Initialize the library */ Rendering::Rendering() { mClock = new Clock; } Rendering::~Rendering() { shutdown(); } bool Rendering::initialize(uint width, uint height, bool fullscreen, std::string window_title) { if (!glfwInit()) { return -1; } /* Create a windowed mode window and its OpenGL context */ window = glfwCreateWindow(640, 480, "Hello World", NULL, NULL); if (!window) { glfwTerminate(); return -1; } /* Make the window's context current */ glfwMakeContextCurrent(window); glViewport(0, 0, (GLsizei)width, (GLsizei)height); glOrtho(0, (GLsizei)width, (GLsizei)height, 0, 1, -1); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glfwSwapInterval(1); glEnable(GL_SMOOTH); glEnable(GL_DEPTH_TEST); glEnable(GL_BLEND); glDepthFunc(GL_LEQUAL); glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST); glEnable(GL_TEXTURE_2D); glLoadIdentity(); return true; } bool Rendering::render() { /* Loop until the user closes the window */ if (!glfwWindowShouldClose(window)) return false; /* Render here */ mClock->reset(); glfwPollEvents(); if (mClock->step()) { glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); glfwSwapBuffers(window); mClock->update(); } return true; } void Rendering::shutdown() { glfwDestroyWindow(window); glfwTerminate(); } GLFWwindow* Rendering::getCurrentWindow() { return window; } } Renderer.h
      #pragma once namespace Game { class Clock; class Rendering { public: Rendering(); ~Rendering(); bool initialize(uint width, uint height, bool fullscreen, std::string window_title = "Rendering window"); void shutdown(); bool render(); GLFWwindow* getCurrentWindow(); private: GLFWwindow * window; Clock* mClock; }; } Timer.cpp
      #include <GL/glew.h> #include <GLFW/glfw3.h> #include <time.h> #include "Timer.h" namespace Game { Clock::Clock() : mTicksPerSecond(50), mSkipTics(1000 / mTicksPerSecond), mMaxFrameSkip(10), mLoops(0) { mLastTick = tick(); } Clock::~Clock() { } bool Clock::step() { if (tick() > mLastTick && mLoops < mMaxFrameSkip) return true; return false; } void Clock::reset() { mLoops = 0; } void Clock::update() { mLastTick += mSkipTics; mLoops++; } clock_t Clock::tick() { return clock(); } } TImer.h
      #pragma once #include "Common.h" namespace Game { class Clock { public: Clock(); ~Clock(); void update(); bool step(); void reset(); clock_t tick(); private: uint mTicksPerSecond; ufloat mSkipTics; uint mMaxFrameSkip; uint mLoops; uint mLastTick; }; } Common.h
      #pragma once #include <cstdio> #include <cstdlib> #include <ctime> #include <cstring> #include <cmath> #include <iostream> namespace Game { typedef unsigned char uchar; typedef unsigned short ushort; typedef unsigned int uint; typedef unsigned long ulong; typedef float ufloat; }  
      Game.zip
  • Advertisement
  • Advertisement

DX12 How do I start with destruction in graphics (DirectX12 or OpenGL) without the use of third party libraries.

Recommended Posts

That means how do I use base DirectX or OpenGL api's to make a physics based destruction simulation? 
Will it be just smart rendering or something else is required?

Share this post


Link to post
Share on other sites
Advertisement

Destruction generally has very little to do with the graphics API. It's all about your code manipulating the mesh data that forms your world.

If your game is designed such that destruction can only happen in a fairly controlled fashion, you can pre-split your meshes into multiple parts in your 3D modelling software, and then at runtime just detach the parts from each other when destruction occurs, and continue to simulate each part separately. 

If you need to be able to damage arbitrary meshes at runtime, you'll need some sort of CSG (Constructive Solid Geometry) algorithm to actually split meshes (lots of fun stuff here, as you'll need to delete triangles, insert new ones, fix up texture coordinates...).

You can also go the voxel direction, and build the whole world out of voxels. Then destruction consists of applying CSG operations to the underlying voxel data, and re-converting modified data to polygons. This is one of the more conceptually simple routes, but voxels in practice come with a surprising amount of additional complexity.

Share this post


Link to post
Share on other sites

Some use-cases come to mind with using a graphics API for destruction. One can use GPU to accelerate physics simulation, which comes in handy if a model would be destroyed into many pieces. I imagine there are also GPU algorithms to compute voronoi noise for a nice procedural shattering effect. Also, a huge amount of voxels can be manipulated on the GPU. Also, rendering voxel based scenes could call for a nice GPU based algorithm.

Just food for thought, you can use just about any modern graphics API for these. :)

Share this post


Link to post
Share on other sites

I can add here what generic destruction algorithm can look like (in short):

 

Given a mesh, and impact point(s) - which can be detected with any collision detection libraries - we generate a set of points on mesh surface (they are not randomly placed, but they are more dense around impact point, more sparse further away).

These are now used for generating voronoi diagram - for each point there will be a set of planes separating it (from neighboring points) - these planes are used to slice out part of mesh and also re-construct 'interior parts' of what is sliced out. These 'meshes' will be convex (assuming original mesh was convex - which is always a better alternative, and it's perferred to do convex de-composition of original mesh).

Each of these new objects also gets assigned convex collider and rigid body physics - co they behave physically.

 

This is also known as Voronoi shattering.

 

As you can see, nothing about 3D graphics api is actually mentioned, as any graphics api can then be used for rendering of objects after performing shatter. You're also free to use any physics library (you will most likely need basic collision detection and rigid bodies for realistic simulation).

 

Also as the algorithm is computationally intensive, you can actually pre-compute the shatter, and do just re-placement of original object with shattered objects (giving them collider and rigid body). Let me link you a video:

We've used this effect in game for Ludum Dare, shatter mesh was pre-generated. The actual activation of physics is delayed for specific parts of shattering object - due to design of the game.

Share this post


Link to post
Share on other sites
On 3/3/2018 at 11:59 PM, swiftcoder said:

Destruction generally has very little to do with the graphics API. It's all about your code manipulating the mesh data that forms your world.

If your game is designed such that destruction can only happen in a fairly controlled fashion, you can pre-split your meshes into multiple parts in your 3D modelling software, and then at runtime just detach the parts from each other when destruction occurs, and continue to simulate each part separately. 

If you need to be able to damage arbitrary meshes at runtime, you'll need some sort of CSG (Constructive Solid Geometry) algorithm to actually split meshes (lots of fun stuff here, as you'll need to delete triangles, insert new ones, fix up texture coordinates...).

You can also go the voxel direction, and build the whole world out of voxels. Then destruction consists of applying CSG operations to the underlying voxel data, and re-converting modified data to polygons. This is one of the more conceptually simple routes, but voxels in practice come with a surprising amount of additional complexity.

So you are saying destruction is about how to use maths to manipulate geometry, vertices, indices per frame in rendering loop?

Share this post


Link to post
Share on other sites
2 hours ago, ritzmax72 said:

So you are saying destruction is about how to use maths to manipulate geometry, vertices, indices per frame in rendering loop?

It's mainly about physics. If you want to do this yourself it will be by much the hardest part. You need a rigid body simulator, which consists of collision detection, solving for contact forces and so forth. So first you need to decide to spend at least a year on that, ore use a library. Physx is popular for massive destruction on GPU, you could use just that. 

Then, as Swiftcoder already said, decide if you can precalculate the pieces, or if you need to calculate destruction on the fly. Convex decomposition is no easy task either. Here's one library: http://kmamou.blogspot.co.at/2011/10/hacd-hierarchical-approximate-convex.html Physics engines probably provide their own. Doing this in realtime is very unlikely - you'd probably better cheat. (Let the original object disappear and repalce it with pieces that have a similar shape.)

There is nothing special about rendering. Doing the physics simulation on GPU might make sense. Usually this means again cheating where possible to keep things fast. There are many papers around about this. Approximating bodies with spheres, position correction, ...

 

So, either use libraries and make games, or spend years on research and hard work with risk of failure but lots to learn.

Both have their value, choose wisely... ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement