Speeder

@Minime891 sorry it might take some time since I'm rewriting the tool from scratch (with missing file format support, like .uva and .pmi). :D

@TDUZoqqer I didn't give a thought to it yet. :D Using a blur mask should be good enough (the whole procedural wheel blur they use in Forza is probably way overkill).

TDU2 probably use the same system as TDU1, so the distant sector (here the moutains) uses the 'Area-x-x-x-x' geometry file instead of the 'Sector-x-x-x-x'. To put it short: - An Area folder contains several sectors files + a area bnk, which is used as the highest LOD (level of detail) on the map screen and in game (for the farest sector that's not loaded into memory yet) - A sector acts as the lowest LOD and is (afaik) only used in game. It also contains multiple LOD for sector specific geometry (e.g. lighthouse, ...) as well as an heightmap for the terrain (which is splitted into several patches for tesselation) There might also be a way to edit the way the game streams the sectors (by adding more sectors to be loaded into memory) if it's not hardcoded into the game code. :geek:

[quote name='Minime891'] @Speeder It would be cool if you could look at it but i understand that you have chosen to put your time into some thing else. With out .shk there is nothing that can be done as i'm sure you know.[/QUOTE] I've already started rewriting the whole thing (including bnk depack/repack so that you don't have to repack it yourself, proper terrain tessellation management, multiple sector edition, ...). Havok stuff is next. :D

Don't expect too much from the .shk generation, as far as I remember the MOPP (the bytecode used by the physics engine) generated is totally wrong. I guess it could be cool to give it some time and rewrite a tool for map edition (research papers on MOPP emerged those last years). :D

@Ryzza5 Yep that's exactly how it works :D

Since I'm currently working on a virtual file system (GitHub - ProjectHorsepower/horsepower at modern_io), I thought it would be nice to write a small post about mods (well at least how I plan to implement these). :) Mods are split in two categories: Local Mods: mods applied locally; meaning others won't see the mod. This is typically anything that doesn't interact with gameplay (3D models, sounds, textures, graphics effects, ...). Global Mods: mods applied globally. This kind of mod would be stored on the server, and shared to the connected clients (either direct download via HTTP or simply ask the user to download the mods from an external link). This kind of mods cover everything the local mods don't (3d levels, physics settings, gamemode, time of day, etc.). What does it have to do with the virtual file system thingy? :D Thanks to a virtual file system (vfs), you can virtually build a directory from different locations (zip archives, disk folders, network content, ...). And that's where it gets interesting. With that setup, you can easilly extend the game content without touching your base data. It basically means mods can be shared as zip archives, drag 'n dropped to the mods folder and that's all. If the mod doesn't match your expectations, and you want to uninstall it, you simply remove the archive from the mods folder. Another interesting feature (not implemented yet, but shouldn't take too long) is stackable mods, which let you override other mods content without needing to disable/remove these. Example: -Mod A introduces new car model CarModelA, with its own set of texture, 3d model, sound, ... -Mod B replaces CarModelA texture set, and introduces new textures for environment -Mod C replaces CarModelA sound -Mod D replaces CarModelA texture set, overriding Mod B (but doesn't disable the new textures introduced by mod B) This would work either automatically (based on the archive date) or manually (introducing a priority index or something like that). The folder hiearchy would look something like this: | Game.zip (base game data that should not be modified) | Game/ (folder containing permanent changes, if you want to override base game data) | Mods/ (folder containing mod archives, which can be added/removed on the fly) | Game.exe Last week progress (warning: contains geeky mumbo jumbo :p): Implemented GameObject binary serialization/deserialization Better GameObject API (e.g. component can be added in a template fashion, 'gameObject->AddComponent<Mesh>( "Tree.mesh" )') Better unicode support (which should allow to port the code easilly to *nix or MacOS later)

I fail to see how both project are incompatible. Plus your work on UI looks pretty great, it would be a waste to throw that away don't you think? :)

@Diablo: roger that :D I have setup a git repo with the current codebase: [URL='https://github.com/ProjectHorsepower/horsepower']GitHub - ProjectHorsepower/horsepower: Horsepower - MMO Racing Game[/URL] The code should be compilable (as long as you follow the Readme). There is not code guideline/contribution guide whatsoever yet, if people are willing to contribute I'll make one. :) I've also made a [URL='https://trello.com/b/XgBYgiT3/']Trello[/URL] to manage the project's roadmap

@TDUZoqqer: right now it roughly takes 3.5ms per frame (with temporal reprojection enabled) at 1080p, which is expensive I have to admit. It should be possible to go below 1.5ms ([URL='http://advances.realtimerendering.com/s2017/Nubis%20-%20Authoring%20Realtime%20Volumetric%20Cloudscapes%20with%20the%20Decima%20Engine%20-%20Final%20.pdf']as suggested by Guerrilla Games presentation[/URL]) with some optimization. I guess UE4 volumetric clouds implementation is based on this paper as well, so it should be viable to use these for high quality settings. :) Raycasting; as you already mentioned it's really hard to get stable constraint-based physics (well unless you write your own physics engine as the guys behind BeamNG did :D). My implementation is really basic right now (e.g. I only apply a single force on the hull, I don't support gearbox yet, ...) but is stable even at low framerate.

I hope something as simple as a sandbox editor (like TDU challenge editor or Halo's Forge), in which you'd simply drag and drop entities and voila! :D Yeah that's the problem with C++. I'd love to add node-based scripting to make contribution easier, but I don't have enough free time to do so. :p I should setup a repo quite soon (on github or bitbucket) so that people can have a look at the code and (eventually) contribute to the project. Anyway some recent (visible) progress: volumetric clouds (with unfinished lighting) and anti aliasing (which still need some work)! I've also started reworking physics (which still need loots of work).

Project Horsepower Github | Roadmap | Twitter The project I don't plan building a AAA-scaled game nor a real open-world like Forza Horizon 3 or The Crew (with a 0$ budget and a one-man sized team this isn't realistic at all). Instead, the whole idea is to create an open-world racing game with high quality features (physics, graphics, multiplayer, gameplay, ...) and as much content as possible. I might receive help for asset creation (or might even end up setting up a Kickstarter to get a budget to hire freelance artists); I just don't know yet, this isn't my top priority right now. The most important part of the project is modding: everything is moddable. By everything I mean: graphics (models, textures, materials, ...), physics (per vehicle or per 'world'), audio, game modes, ...* The mods will either be applied on the server side or on the client side (with more or less restrictions depending on the kind of mod). *: some stuff aren't implemented yet so I can't guarantee everything will be part of the final product The game Gameplay One word: MULTIPLAYER. To put it short, there won't be any solo/offline activities (except offline free-roam). The project is still at an early stage so I can't really talk about the game modes without being a Peter Molyneux copycat (no offence to him). You should expect free roam, races, cat and mouse, car ball, CTF, user-made mods, ... I'd also like to add some aspect of TDU1 (the whole real estate thingy, car dealers, road discovery, ...). But again, I'll come back to these later. Physics I guess it's a matter of taste, but I think a MMO racing game should aim for semi-realistic/arcade physics. The current state of the physics is closer to arcade than simulation (since a lot of components are missing) but in the end it should be close to semi-realism. Graphics Nothing too out of the ordinary here, this is basically what you may find in any other game. Special attention will be paid to the car paint. As you can see in the screenshots below, there is still a lot of work to do. Network Another huge part of the project. Right now, the game can handle up to 24 players in the same session (with each player having a ping <100ms), using exclusively a client-server infrastructure. This should easily be upgradable considering how basic the implementation is right now (no delta compression, lame physics prediction, ...). Notice that game lobbies won't handle as many people as free-roam. Technical Stuff The engine is written in C++ (using C++11standard), scripts in Python and Batch, physics uses Bullet Physics; it supports Direct3D11 as graphics API. The renderer uses Forward Plus Shading, supports point/spot lights and a limited amount of area lights. The render pipeline is PBR (well as much as I can understand what PBR really mean) and uses a dynamic modular architecture (to make it short: it uses less memory and can easily be extended without rewriting a lot of code). Screenshots [ATTACH]30731[/ATTACH][ATTACH]30732[/ATTACH][ATTACH]30733[/ATTACH] Right now, if you have any idea or cool stuff to add to game, questions, ... feel free to post here. :D

Well technically the client could send the hash of the AiConfig file to the server, the server would check wether or not the hash matches with the "official" AiConfig file, and then allow or reject the connection. :) (and eventually display a prompt asking to download the official patch; imo doing a silent download is not right (the player should always know what's going on behind the scene)). But still, I'm not really sure if messing with players' files feel right (and on top of that, I don't think I'd have time to implement such feature :p).

@BeSweeet: Physics wise or graphics wise? :D

@Mademan: I might start a rewrite of the project as well as an update with the missing features (if I can figure out all the missing Gamespy stuff) later this month (but I can't guarantee anything since I'm quite busy in real life, and I'm also working on a simulation mmo-racing game in my freetime :D).