seedhartha
-
Content Count
92 -
Joined
-
Last visited
-
Days Won
11
Everything posted by seedhartha
-
Version 0.16 of the engine has been released, which achieves a major milestone: the Endar Spire has been made completable. This is among many other things, such as lip sync and PBR. As always, if you're interested in checking reone out, you can download the latest release from GitHub, or build it from source. https://github.com/seedhartha/reone
-
Most should, if not all of them. There are things in the engine that we hard-code as opposed to reading them from the game assets, e.g. new animations cannot be added at the moment, but we'll sort it out. As a rule of thumb, mods that create or modify *assets* should work (this includes new areas and scripts). Anything that relies of less studied files, or fiddles with vanilla executables, will not.
-
Thanks! Talking about possible - anything is, this is an open-source project after all. Do I have plans to add anything graphics wise? Not for the time being. I find it much more important to focus on the gameplay - particularly making the first game completable, minus the minigames. Changing vanilla behaviour is kind of a grey area, but that certainly sounds doable. Things like these could work as a feature toggle, I think.
-
This may very well be true if we're talking about creating a new game, but with recreations, you're forced to do things in a very particular way, and to reimplement a lot of stuff, including the scripting subsystem, resource formats and etc. Because of that the benefit of using a third-party engine is much less than it could be, while the costs are still there. As I've said, the hardest part is reimplementing the game logic. I fail to see how a Unity-based project has more chances at being finished and usable than its custom counterparts, which already have the low-level subsytems covered (reone and KotOR.js already do).
-
@sELFiNDUCEDcOMA I think you're misunderstading the idea behind engine reimplementations. None of those are trying to recreate the vanilla engine in a sense of replicating the old technology - they are always based on newer frameworks (e.g. they use modern OpenGL with proper shaders), and they do add a *lot* of value to modders. Being open source, these projects allow modifications (gameplay and graphics wise) that were never possible with the vanilla engine. As the person who have effectively recreated the KotOR engine, I can tell you that using a third-party (proprietary) game engine is actually more of a detriment to such projects - it *hurts* their long-term viability. Recreating graphics, audio and miscellaneous subsystems are least of your worries as the engine developer, since you're going to spend most of your time reimplementing the game logic - this is just as true for Unity-based projects.
-
Alpha is controlled by a separate shader node, which multiplies diffuse texture alpha by model node alpha. You need to change the latter for alpha to be exported - this is by design.
-
Faces have the following structure: vertex_index1 vertex_index2 vertex_index3 smooth_group uv_index1 uv_index2 uv_index3 material The last value, i.e. the material, does indeed get lost unless the model node is a walkmesh. This is the behaviour of original KotorBlender and I don't think it's necessarily wrong. Exported area models seem to work ok regardless of the lost information.
-
Thanks for the feedback. I've fixed the first two issues you've found. Regarding alpha: where are you expecting it to be set? Currently alpha is written to and read from the Multiply shader node (the second input).
-
I've upgraded the add-on to work with Blender 2.8+ - available for download from https://github.com/seedhartha/kotorblender I did not test it extensively, but importing and exporting (skinned) creature and area models (including walkmeshes) works for me. I'm willing to provide support for this version - so, if you encounter bugs, don't hesitate to make a post in this thread or create an issue on GitHub. Hopefully we'll do a merger with @ndix UR as some point - wouldn't want this to take too much time out of the reone project 😅
-
Lighting in these screenshots consists of both dynamic lights and self-illuminated meshes converted to light sources - no changes were made to the vanilla assets. What exactly is causing the cyan lightspot there is hard to tell. I'll stress once more that in order to fully utilize PBR, modders would have to provide additional data: either separate metallic/roughness/AO maps per each diffuse texture, or at least a lookup table of metallic/roughness parameters. Here I've set metallic at 1.0 and roughness at around 0.3 across all surfaces - ideally all of those would react differently to light.
-
I wouldn't bother making another video of this, but here's some screenshots to give you an idea:
-
Thanks! PBR is not available in 0.15, hence "feature preview" in the video title. Currently, you either want to build reone from source or wait until I release the next version (which will take some time, as I intend to make Endar Spire completable with it). Regarding launch: specifying the game path should be enough, yes. Did you install the VC redistributable, as the readme suggests? Other than that, you want logs to diagnose problems: either start reone from the command line, or add "logfile=1" to the config file and look for "reone.log". Regarding graphical capabilities, current light limit is 16 lights (easily extendable). There is also an experimental feature to convert self-illumed models to actual light sources, which does spice interiors quite a bit. Ray tracing is not entirely out of the question, but the engine would need to be rewritten to replace OpenGL with Vulkan. Definetely not something I'm interested in for the time being. Also, keep in mind that to fully utilize PBR, vanilla assets need to be augmented with additional data: metalness and roughness parameters, per each diffuse texture, which I setup by hand for the preview video.
-
I keep a tab on performance and try to use modern OpenGL functions and optimization techniques whenever it makes sense. As it stands now, reone pushes hundreds of FPS in a typical module on my machine, noticeably more than I have using the vanilla engine. And yet, there are still ample optimization opportunities I can think of. You can expect reone to outperform vanilla, if only due to advancements in OpenGL. Grass is currently not implemented at all, but I see no reason, why you wouldn't be able to increase the grass distance or crank any other graphical setting up.
-
Being able to play the entire game on a modern engine is kind of the whole point 🙂 Since this is essentially a one man project, I cannot promise to make an exact replica in terms of functionality, but it should be reasonably close. Mod support is going to be hit-and-miss, but as a rule of thumb, most of them should work out of the box, as long as they add or modify vanilla assets, and do not fiddle with stuff on a lower level.
-
Since reone already uses multi-pass rendering, there's nothing stopping you from writing a post-processing shader. That's how self-illumination currently works, for example.
-
Greetings, I'd like to share with you the project I've been working on since summer 2020. Some of you may already have heard of it, as the development was public from the beginning. reone is an open source reimplementation of the KotOR engine, similar to xoreos and KotOR.js, but with a number of key differences. It is developed with extensibility in mind, meaning that modding capabilities it aims to provide are on a whole other level compared to the vanilla engine. For example, the graphics have already been significantly improved with the addition of physically based rendering. Current state of the project is such that the most fundamental engine subsystems are either complete or at least partially implemented, i.e. resource management, rendering, audio, GUI, scripting, conversations, combat and more. Given the current pace of development, I intend to finish the project by the end of 2021. My short term goal is to make the first Endar Spire module fully completable - a milestone, that will hoperfully bring more attention to the engine. Technologically, reone is a custom engine based on SDL 2 and OpenGL 3.3, written in C++14. This alone makes it highly portable - reone is believed to be working on Windows, Linux and Mac OS. Some background on myself: I'm a professional software developer from Russia and a prior contibutor to the xoreos project, responsible for most of its recent progress on KotOR. Links: GitHub Page Project Roadmap YouTube Channel
- 39 replies
-
- 12
-
-
