Jump to content
  • Advertisement

Vilem Otte

  • Content Count

  • Joined

  • Last visited

  • Days Won


Vilem Otte last won the day on October 6

Vilem Otte had the most liked content!

Community Reputation

3199 Excellent


About Vilem Otte

  • Rank

Personal Information


  • Twitter
  • Github
  • Steam

Recent Profile Visitors

32934 profile views
  1. Vilem Otte

    Bare bones AAA team

    I will just input salary for my country (Czech Republic, next to Poland) - for software developers, so you get the picture. For senior developers the statistics says that on average they require $40,000 per year. For junior developers it is $18,000 per year. These are netto - as it is reported salary by the employees. (Source: Startupjobs.cz) So, your income budget would be (our taxation is around 45%) at $73,000 for seniors and $32,000 for juniors. As senior we generally count somebody with at least like 5 or better 10 years of experience. Often also working for foreign company for few years. Of course the salary heavily varies based on the branch where you work. Of course, you can also try luck in India, which may be even a bit more cheaper - forming even bigger team. The problem is, bigger doesn't necessarily mean better. And when you have to aim at qualified people (often with university degrees and experience) that know what they are doing, the costs difference tend to decrease.
  2. Vilem Otte

    DOOM: Placeholders

    Currently, the only "playable" level is still full of placeholders - I'm still hoping for having the game finished on 18th, but we will see. In worst case - there might be some place holders left (while the game would still be playable). In the meanwhile I have added: Full physics (based on Bullet), not just character controllers, but even rigid bodies are technically supported (I'm still not sure whether I will do anything with them) Ability to control behavior of entities (doors, elevators and such are possible - but I don't think I will have enough time to make art for those, so we might be limited here) Improved the speed of dynamic BVH building by about factor of 10+ (by simply going through my code and removing dumb things) Get rid of most of the limitations (like total texture size was originally limited to just 8192x8192 texels, technically this is much higher now) Finished some sort of player movement I'm kind of satisfied with I'm realistic, the competition ends in about 2 days (and as most of us - I still have to be at work during those). I personally will be glad if I manage to make the scope I wanted for proof of concept demo - that includes: Simple menu (New Game/Exit) Single level Single type of enemy Single weapon Player can die in the game and player can win the game Some sort of Doom-ish UI Some advanced ray tracing effect or two I know this isn't much (and is most likely barely covering the scope for the challenge). In the meanwhile - behold - the placeholders (and no that 0.44 GRay/s is not joking - I'm currently limited by performance of actually displaying the buffer, not ray tracing nor BVH updates at all)!
  3. Vilem Otte

    Bare bones AAA team

    The Witcher 3 development costs were 306 mil. PLN - if you would convert that into USD that is $81 million. Witcher 3 is one of the largest open world RPG games I have played in past few years. I would say that it was a AAA experience. The Witcher 2 development costs were around 40 mil. PLN - about $10 million. I would dare to say that Witcher 2 was also AAA experience, despite being much shorter and not open world like its successor. It is considered as one of the cheaper AAA games. These games were developed in Poland, the costs for employees and living are slightly lower compared to Western Europe, and a lot lower than in F.e. California. You also need to take this into account.
  4. Vilem Otte

    Ludum Dare 45

    Introduction Yet another Ludum Dare event was around, and I found time to participate this time again (this time it is actually 10th Ludum Dare I've participated in so far). So, first of all - if you are interested, just roll down the post and play the game. Short gameplay video: Fig. 01 - A short gameplay video. What went right? This time around, we have decided to dive into the wonderful world of procedural generation quite fast, the actual work on the game started early saturday morning. Being heavily inspired by Angband, the decision was clear - our dungeon levels must be generated. Procedural generation of such dungeons is not really that hard, I have started off with simple algorithm and worked from there: Generate a 2D axis-aligned BSP tree, randomly terminating after at most N levels or when criteria is met Shrink rooms represented by leaves of the BSP tree Make connections in bottom-up order (first between leaves, then between interior nodes and leaves - picking always the closest room to the currently processed one). The results were quite promising, producing blocktober worthy images like: Fig. 02 - Randomly generated dungeon level At this stage entrance and exit were placed, followed by the monsters and power ups which you can pick up in the dungeon. The last thing to solve in level design were first and last level. Although as our levels during the generation phase are defined as byte arrays (containing actual chars defining what is on given tile) we simply used file and injected it into the process. Our first level looks like this: ### ###X### #.#...# #....## ##....# #...#.# ####### Where: # - represents wall . - represents empty space X - represents exit out of the level Apart from actual procedural generation, the development went quite smooth. I enjoyed making a non-realistic cartoon-ish models, and skeletal animation enabled just for the character hands. The models ended up being quite cute in the end: Fig. 03 - Mushroom in Unity engine editor, version without hands The game mechanics also overall felt quite comfortable (as I'd say finished enough to be playable), compared to some of my previous entries. Picking a smaller scope game definitely played in favor of this. What went wrong? As usual, time. Each game jam (and it doesn't matter whether it is Ludum Dare or anything else), it comes to the point where you have to start cutting features out to make it on time. Because at the end of the day for game jam, you either finish a game or you don't. We had to cut out various features that would make the game a LOT better, but most important of those was audio. Sound effects and music tend to improve the atmosphere a lot - or to be precise - it is one of the most underestimated feature of the game, with which atmosphere rises or completely falls. Due to our time constraints we ended up completely without audio in the game. User Interface, second item we left for the last moment of development was user interface, and we ended up having it very simple. While being informational enough for the game, making it graphically more attractive would improve the gameplay a lot (compared to having just default text giving you all the information you need). Next time around, I'd like to dedicate at least few hours on these two topics, even sacrificing some of the visual effects or details in world generation, to increase atmosphere of the game with audio and UI. Conclusion As said, this was 10th Ludum Dare for me, and I have enjoyed working on it very much. I'm quite satisfied with the game we have ended up with. For the next time, assuming I would have a free weekend, I'd like to participate again. Also, if any of you (who read this article) have participated in Ludum Dare, and would like me to play your game - please leave a comment here, and I will definitely play your game during the following weeks. Goodies So, for curious ones (I'm intentionally leaving just Itch.io link to the game, as I never know when I will remove it from the server - that would make the link inactive): Source code is available at: GitHub Game is available at: Itch.io Ludum Dare page is at: LDJAM
  5. Vilem Otte

    DOOM: Skeletal Animations & Dynamic BVHs

    @lawnjelly If it goes well, I'm considering either: Changing repository status to public on my server (maybe fork it to Github) Publishing that ray tracing library as a library (with few examples) Writing some articles about ray tracing dynamic scenes The library I'm using (a custom one) is OpenCL based renderer - it doesn't have hard syntax (it might need a review or two - and maybe updating the interface after the project - as I'm adding classes/methods whenever I need them for this project). I'm currently busy making and animating a daemon from hell. 100% programmer's art.
  6. A small update I was tackling today - and that is skeletal animation. Now, doing anything animated with ray tracers is quite a pain... Static scenes - you simply build acceleration structure once ... and then you can move camera around, and everything tends to be nice and easy Scenes with dynamic objects - multi-level BVHs can rescue you here, you build bottom level BVHs and then rebuild top level BVH, also this enables instancing as side product Scenes with dynamic geometry - you may go a bit nuts in here, as you NEED to rebuild BVH for given geometry So, current strategy for the DOOM project is somehow working, basically the scene allows you to add render nodes, which can be defined as either STATIC or DYNAMIC. The STATIC ones have BVH built once in the beginning, and never rebuilt again. On the other hand the DYNAMIC ones have BVH rebuilt every single frame. All of these bottom level BVHs are then leafs of top level BVH that is being rebuilt every single frame. My apologize for giving this in form of small post, and not a full featured article (once the Challenge is over, I already have quite a pile of topics I'd absolutely like to write about, most of those are related to ray tracing). In the meantime, I can at least feed you with simple sample...
  7. Vilem Otte

    DOOM: Multi Level BVHs

    @LandonJerre I'm glad to hear it is running on RTX 2080! Thanks for testing. I've figured out one application crash (BVH had a memory leak - and as it is rebuilt every frame, you can run out of memory quite fast), this might have been the cause of it. I was able to reproduce vertical black line on my GPU either - will look at it eventually (added into TODO list). Seems like RTX 2080 gives the highest performance so far (for later releases, I may want to add a way to send results to database (with hardware information and resolution)), that way we could compare how fast which GPU is - and I could make a minimal and recommended configuration (plus what resolution you should run) once the DOOM game is more game-like.
  8. Vilem Otte

    DOOM: Multi Level BVHs

    @dmatter Wow, I really didn't expect it running on Radeon HD 7790 (it is after all a bit older GPU). Now I can't test it on any NVidia directly (as I only have a friend who has it), which isn't really good - so I'll probably get one 2070 before end of September, so I can debug & run on it.
  9. Vilem Otte

    DOOM: Multi Level BVHs

    @JoeJ Thanks. Sounds good! @Rutin I'll try to add a bit more statistics and logging, to see why (it could be that I'm using too big surface for texture atlas, or too large workgroup).
  10. Vilem Otte

    DOOM: Multi Level BVHs

    One of the major challenges in real time ray tracing are dynamic scenes. It is not hard to pre-compute BVHs and then just render the scene, but working with dynamic objects and geometry is challenging. To handle such scenario I've implemented multi-level BVHs where top-level BVH is rebuilt every single frame, additionally for fully dynamic geometry I've added HLBVH (which is extremely fast to build). The first test I have (which you can try) is a Sponza atrium, which creates each single object in it as node within multi-level BVH. Each node has high quality SAH BVH pre-computed on start, and then a top-level BVH is built every single frame. Additionally it immediately supports instancing, which is a great feature! Geometry also have material (with diffuse map) assigned. To run demo, OpenCL 1.2 compatible hardware is required (I've tested this on AMD Rx 380, AMD Rx 590, NVidia 1070 and Intel HD Graphics 620 - where it runs quite slow, but still - runs) Raytracer Test No. 1 I don't like to promise future features, but if everything goes well - I'd like to have some skeletal animated model in soon along with finally some models that I'm working on for the actual game!
  11. Vilem Otte

    DOOM: Challenge accepted!

    I have been deciding to participate in Challenges for quite long time, mainly because I personally wanted to. And when DOOM was voted in, I decided I had to participate. Of course I have to start somewhere (I made a road map, which is something I'm trying to hold to - and throughout the challenge I'm going to switch between working on art and working on source code). So let's consider this as first post, and let's see what I will manage to finish in the end. A little sneak peek into how the project is looking at current stage. Some of you may have recognized that this is Sponza Atrium model (it is not easy to recognize it though - as the image is actually showing barycentric coordinates in red/green channel and distance traveled along the ray in blue) which I'm using for testing, as I'm working on using a custom GPU real time ray tracer as renderer (it is DOOM after all, which originally used a ray caster - so for me, it was natural to use a ray tracer).
  12. Vilem Otte

    Navigation meshes and pathfinding

    @Kylotan I was more pointing directly to the Funnel algorithm in case of Navmesh pathfinding (which is technically post processing step). My problem at the time was - that I had a planet with features on it (in reality it could really be any geometry - toroids, various space stations, etc.). By voxelization (voxelize all walkables, and then subtract all non-walkables) and then applying marching cubes algorithm I built a navigational mesh - which I also used to create a graph (i.e. triangles being nodes and edges of graph were connecting neighboring triangles). Finding the list of nodes to traverse when going from point A to point B was done with A* - so again straightforward. The problem was path optimization - to make the path look nice - i.e. a string pulling algorithm. The pseudo code in articles for those is mostly done in 2D assuming planar like map with single upwards direction. There were multiple solutions I have tried back then: treat it as spherical geometry (which works very well for such planet-like shapes - as long as you move on the surface), spherical geometry is not that hard once you get used to it another option is to use a common 'upward direction' for each 2 adjacent triangles you walk over which is F.e. normalize(N1 + N2) where N1 and N2 are triangle's normals. Project both triangles along this direction and you have your 2D coordinates for current step in Funnel algorithm I have already finished it back then and was quite satisfied with results. While that personal project never got finished, I still use the pathfinding algorithm and navmesh generation in my source code. Note: If I'm not mistaken (correct me if I'm wrong) - most of commercial engines does not support these like navmeshes (and I know this is a bit of corner-case scenario). I.e. try generating navmesh in engine of your choice for sphere on which characters could walk like on planet (i.e. center of gravity is in its center) - I don't think it is supported at all (at least it wasn't last time I've checked in Unity).
  13. Vilem Otte

    Navigation meshes and pathfinding

    @jb-dev and @thecheeselover I see thanks. In terms for navmesh generation I have tried: navmeshes directly created by artists (these tends to be bad, as artists generally don't understand navmesh that good - but they asked whether they can have control ... this didn't work in the end) navmeshes generated by artists by setting walkable/obstacle on surface - geometry then gets voxelized (varying voxel size - this can be used to simulate navmesh agent size ... first voxelize walkables, then 'subtract' obstacles), and then triangulated, this works quite well (although is computationally quite heavy - but can be preprocessed) the same as 2, but geometry doesn't get voxelized, instead it is getting clipped (supports just bounding boxes for non-walkables now) - generally - clip your walkable geometry with non-walkables, and then triangulate result. varying agent size could then be solved similarly to what you have described. Currently I'm still sticking with the middle one.
  14. Vilem Otte

    Navigation meshes and pathfinding

    Nice article! As I've been implementing NavMeshes myself - in most online resources I've missed some further description (majority of articles mention Funnel algorithm, but very few actually describe it in pseudo-code - that is the one thing I'm missing in this article, although from my own experience I know it takes a lot of time to write articles, and they simply can't contain everything). Now, as for NavMesh itself (and my personal curiosity!) - how do you generate navmeshes? Do you take agent sizes into account (and how?)?
  15. Vilem Otte

    Engine: Virtual Textures

    Implementing terrain tools is somewhat time consuming (in addition with me being quite busy in past 2 months - on topics I can't write too much about). Anyways terrain system and authoring tools in my engine start to look good, here is a small sneak peek: The circular thing is a terrain, some interesting features: Height map is a virtual texture of unlimited size (those who know how virtual textures work know that there are some limitations - related to your page table size, page indirection size, etc.) Virtual texture is editable by the user with base functions (I'm currently working on placing 'stamps') Terrain geometry is using seamless LOD using tile-based binary triangle trees Calculation of terrain LOD is based on specific position Allows to specify quality of rendering for shadowmap/voxelization/etc. Etc. The interesting part is selecting which tiles and at what quality are going to be loaded/rendered. I'm not using the approach RAGE used (i.e. not using feedback buffer), but I'm using selected LOD for given terrain tile (currently without frustum culling - which is still on todo list). Originally I wanted to have basic terrain support, but due to myself thinking about more and more features, and adding them - it is becoming quite big. The source still needs a bit of cleanup (before I write something on terrain) and I haven't connected it with vegetation nor physics system yet - these are both in todo list for now.
  • 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!