Jump to content
  • Advertisement

Leaderboard

The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation on 09/21/19 in all areas

  1. 1 point
    I doubt, that you will find anyone here, who has. There are so many resources on this topic out there and the chances that a person who has read this book stumbles across this thread are rather small. Even if, you get lucky there is still the question if this person faced the same problems as you do. So let's focus on your specific problems and let's try to solve them. So you have basically no experience in how c++ programs are structured and how they are composed. Nothing to be ashamed of, but using Microsoft Visual Studio is the worst thing you can do right now. Not because it is bad but because it is good. It does so much work for you that you usually don't need to know much about how your program is composed... until there is a problem. I know that from personal experience. I started learning c++ with VS and had a lot of linking problems I did not understand. I opened a lot of threads in forums where people told me which flags I had to change in some hidden options menu. It magically worked. I did not understand why but I was happy until I hit the next problem. I could have saved myself a lot of trouble, if I have learned the necessary lessons about the c++ build system. Unfortunately, the things modern IDEs offer, which make the lives of experienced programmers so much easier, are somehow bad for Newbies. So my first advice: Do some simple C++ tutorials without using an IDE. Write makefiles, multiple mini-libraries and link them all together. If you don't make any mistakes (unlikely, but might happen), try adding one on purpose and see what happens if you want to build the program. You need to learn how the compiler/linker addresses certain error types, which leads me to the next point: How cute, just 612? Try hitting 1000 or 10000. It's not that hard to achieve. 😛 Jokes aside. The number of compiler errors you get is absolutely irrelevant. The only thing that matters is the first one. If you forget to include a file where a certain function is defined, the compiler will create an error every time you use this function. I can only support the things @Kylotan mentioned. Try solving all errors step by step. Always solve the initial error and don't bother with the others which are probably just subsequent errors. If you don't know how to solve a specific error, ask and give us the error message and the code section that caused the error. We can't help you if we don't know, what is supposed to happen. If the program compiles, you have at least a more or less working program. If you run the program and you get no output there might be multiple reasons: - The program is not supposed to print any output. - The output is written to a file that you have to open with a certain software tool (ParaView is quite common in Physics simulations) - The program crashed. In this case, you should get at least an error message which you can provide to us. So please tell us, what the program is supposed to do and what it is actually doing. I stopped using VS a long time ago, but I think the VS Version which was used to create the file is somehow important and you might face a compatibility problem here. But that's some wild guessing from my side. Maybe a more experienced user can tell you something about it. However, I suggest you put the book aside for a while and start learning the basics of c/c++. This is not an easy task since c/c++ are rather difficult languages, so it will probably take some time. In my opinion, it makes no sense to learn programming game physics without some solid knowledge about the programming language you intend to use. It will just frustrate you. Greetings
  2. 1 point
    Biggest thing, ASK FOR HELP. I see this a lot with juniors they come in and agree to everything and when they get stuck they panic and don't tell anyone. You are a junior you are not supposed to know much and the codebase will be brand new, especially since it's your first job. Nobody cares if you ask for help and it actually looks better than at the end of the day finding out you have been working on a problem already solved someone could of told you quickly. Everyone expects you to be there to learn just as much as you are to work.
  3. 1 point
    I'd like to say a few things, since I've recently written a voxelizer in compute and done a fair amount of research: 1. GPU Rasterization to voxelize high poly meshes is a bad idea. GPUs are already bad at rasterizing tiny triangles, but this gets further aggravated by the fact that this approach requires interlocked operations and the high density of vertices means there is a lot of contention due to multiple threads trying to write into the same voxel block. Some papers mention their implementations have a drastic time increase with poly count due to contention. Triangle density per voxel also plays a big role, because it's not the same to have a mesh that has each voxel touch one or two triangles, than a mesh that has a single voxel with 600 triangles going through it. Another problem which most papers except a few often fail to mention (probably out of ignorance) is that unless the voxelization process is very simple, you need to blend your results; and there is no "interlocked average" instruction. Therefore implementations perform a mutex-like locking of a voxel. This is a problem because such approaches can result in an infinite loop because half a warp acquires the lock while another warp(s) acquires the other half, thus they will fight forever for acquiring the lock. Implementations that fail to account for this will result in a TDR, which is not immediately obvious unless you're working with high poly meshes, which is where contention happens and the infinite loop cases appear. Implementations that successfully account for this add a 'bail out' counter: If the mutex acquisition takes more than N spins, give up. This means the voxelization process may not be accurate, and worse it may not even be deterministic. But at least TDR won't happen. You could append those failure cases into a list and process them at the end serially though. The only way to properly implement this is using Independent Thread Scheduling introduced by Volta, and is only supported by NVIDIA GPUs (at the time of writing). This problem may not apply to you though, if you don't need any complex per voxel average/mutex. If a simple interlocked operation (like atomic addition) is enough, then ignore this drawback. You can avoid the "atomic blend" problem if your 3D texture is in float format, and track the accumulated weights in another 3D texture. This consumes a ton of memory. The "atomic blend" problem appears because of memory restrictions, thus we want to blend an RGBA8 texture or similar precision. 2. That leaves the opposite approach: Have each thread perform a box vs triangle test against all primitives. A brute force approach like that is super slow even for a GPU, much worse than doing GPU rasterization. However it can be greatly improved using hierarchy culling: partition the mesh into smaller submeshes, calculating its AABB, and then skipping all of those triangles by performing an AABB vs AABB test. The compute approach can be further improved by having each thread in a warp load a different triangle, and use anyInvocationARB to test if any of the 64 triangles intersects the AABB that enclosees all voxels processed by the warp. If you're lost about this, I explain this optimization in a Stack Overflow reply. While the theoretical performance improvement is up to 64x, in practice this optimization has yield us gains anywhere between 3x-32x depending on the scene involved (often between 3x-4x). This is what I ended implementing for Ogre 2.2; you're welcome to try our Test_Voxelizer.exe sample (build Ogre 2.2 using the Quick Start script). Find a way to load your mesh data as an Ogre mesh, modify the same to load this mesh of yours; and time how long it takes. That way you can easily test if this approach is worth pursuing or not. If it's not, then go back to the thinktank for something else. Note that you should test different values of indexCountSplit in 'mVoxelizer->addItem( *itor++, false, indexCountSplit );' as that value controls how big each partition is, and this can have a huge impact in voxelization performance. There is no 'right' global value, as the best value depends on how your mesh' vertex data is layed out in memory and how much space each partition ends up covering. Good luck Cheers
  4. 1 point
    1) Never work for someone else for free. You have skills, make sure you get paid for them. 2) Avoid religious fanatics. This includes (but is not exclusive to): Scrum is the only One True Development Process people (be Agile and let your project dictate the process, not the other way around) The Object Oriented Programming is the only way to develop crowd. The Cache is King, polymorphism and poorly laid out classes kill it. By extension the patterns crowd where they have a hammer therefore the world is a nail. 3) Avoid people tied to a specific technology. Primarily game engines. You don't always need a game engine to create a game. Opinion here, but I think that the reason why we, as gamers, have not seen any really revolutionary type stuff in the last 10 years or so. Producers are so risk adverse that they are dictating certain technologies thinking they are going to save time (i.e. money) but end up with a sunk cost fallacy. 4) If you are hired by a development house realize that you are a mercenary, companies will not be loyal to you and you will end up in a Death March and not be paid appropriately and typically dumped when the project is cancelled or 'finished' and shipped. 5) Avoid Brogrammer culture at all costs. 6) Don't worry about code reuse, you probably won't reuse code. You will learn stuff and figure out how to do it better the next time.
  5. 1 point
    Like the gun and the level design doodle! Looking forward to seeing it!
  6. -1 points
    The idea being use the Star Wars approach, have the game side and a animation side with stories/episodes. So that each side promotes the other. The games would be all over the place... Rpgs, strategy, simple games and the rest. More like star wars where games are generated off all sorts of eras and content. I have the start of a galaxy, 8 species, the early planetary history and early space in that section of space... Would like to see another 24 species added.. All unique and worth while. Allowing for origin storys for each species Obviously founding members are partners, those that come on later paid help when it generates money. The Galaxy has a few key pieces... No humans... They always become the center point, leaders of both sides and become immortal rulers of the galaxy. This Galaxy would have more carnivores, and naturally violent species. Less alliances/federations... Far smaller groups.
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
      259990
    • Most Online
      6110

    Newest Member
    thomedy
    Joined
  • 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!