![]() ![]() Fixed several crashes when in terrain editing.Removed dead code in preparation for major parser changes.Removed delay from EV_COMMON_RESET_SIMULATION_PACE and EV_COMMON_REPLAY_FORWARD.Removed color tags from actor names in top Menu.Removed hotkey `E` COMMON_TOGGLE_RENDER_MODE.Changed and cleaned up the analog dashboard.Changed the top Menu to hide in free cam. ![]() Changed to only use "nicemetal" materials.Changed the UI behavior if the cursor is focused.Changed Xbox controller input maps to support Xbox Series controllers via Bluetooth.Changed the mini survey map to be less cluttered.Changed prop animations with `eventlock` to remain active if character leaves actor.Changed Conan short paths for GitHub actions Windows build.Changed the parser to ignore 'v' beam option.Added ImGui AngelScript functions, script monitor UI, and `loadscript` command.Added hydro flag `j` and restored `i` for backwards compatibility.Added zoom in and out of the survey map with a mouse wheel.Added key map Xbox 360 Wireless for Linux.Added AI scripted driving modes "drag" and "crash".Added a switch for render modes in Tools.Added the groundwork for Terrain editing capabilities.Added procedural road editing using AngelScript.I am also somewhat concerned about loosing creativity. Downside is that it significantly raises the entry barrier and reduces amount of artists willing to make something which fits very specific requirements, instead of making whatever they want and then sharing their work. Where each category means very specific rules and maybe some reference pieces meant to ensure compatibility. Something like opengame-3drealistic-2020 or opengame-2dtopdown-pixelart-v3. Maybe this would work better if the repository served not only dumb file storage but tried to establish set of target requirements (updated once every few years) to improve the compatibility assets. But even then what's considered realistic 3d game art has significantly changed over the years. It might be slightly simpler if you assume realistic 3d art style. It may look better to have less and worse quality but consistent assets, than more mixed quality assets. You don't want some unimportant background prop to consume more triangles than main player character. Not only 3d model can be too low quality, having too high quality can also be a problem. For example if you want a modular building parts some random assets created by different artists without targeting a specific game requirements will probably not be compatible with each other or building system in game. Not only in terms of art style, but also detail level and technical constraints. Major limitation to this idea is that for a decent looking game the assets need to be consistent. Note, in the video, how soft the suspensions are. Integration of stiff systems of differential equations is Not Fun. If you don't need real time, as for film work, it's not too bad. Also, you start to need double precision. This is possible, but the compute load suddenly jumps by orders of magnitude during some collisions. That's because you have to simulate what's happening on very short time scales, much shorter than a visual frame time. What's hard is doing things which have just a little elasticity. But everything looks like Jell-O, as some early Pixar devs wrote. If you make everything soft, that works OK. This is the main reason game simulations usually look wrong. This looks OK for small objects and terrible for large ones. It suffers from the "boink" problem in impulse-constraint systems, there are instantaneous changes in velocity on collisions. Totally rigid body physics is reasonably well solved by now. It's about typical for modern physics engines. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |