did you plan to replace the renderer (if that’s even possible) or is it a totally different engine those screens were taken from? i second rjshae’s idea. after reading your post this instantly sprang to mind too.
I think it’s very important to manage complexity in order to keep my feet on ground. I’m going to focus only in NWN2 while Xoreos aims to implement several games. I don’t want to introduce any complexity to my code and spend time in order to support other games.
The screenshots are from a totally different engine. Technically I think it’s possible to replace the renderer by hooking the EXE/DLL of NWN2 like NWNX does. But I fear the amount of reverse engineering and hooking needed is quite big.
well, you could just focus on the renderer and let the small team around xoreos do the “game logic” implementation of the engine. this would also help the aurora engine as a whole. this way you won’t dedicate time on other things but graphis. sounds like exactly the thing you talked about in your opening post.
Let’s put an example. If I’m going to implement the water shader, my only goal is to implement a shader for a modernized NWN2. If Xoreos is fine with using that shader for all games, then I’m fine. But if the goal of Xoreos is that each game has a water shader that imitates the original one, then it’s out of my scope.
thanks, now i better understand what you’re up for. dunno what his goals are, but i believe that there will be only one renderer capable to display the different file formats the aurora engine derivatives used over the years.
It would be pretty cool if your renderer could display the underwater portions of any placeables so situated. Right now I believe it only displays the area’s ground surface. Not sure what sort of performance hit that would create though, especially with refraction and caustics factored in.
I would not anchor yourself to Xoreos. As amazing as that project is… it’s also the most unbelievably ambitious project ever as well.
I think you’ve taken a much more realistic approach and agree 100% with it. Avoid scope creep at all costs.
Amazing work so far FreshLook - I would love if you kept a semi-blog or update on your progress / challenges / what your thinking is, either on your git repo or here or anywhere really.
Do you have “Water Refraction” checked in the graphics options? When checked there is refraction effect and the submerged part of objects are rendered.
When I researched the compression algorithm used in the GR2 files a year ago, I didn’t find anyone that had reverse engineered the algorithm. I decided to use the granny32.dll library from the NWN2 install to decompress the GR2 files, but this has two problems for my future plans:
Because granny32.dll is 32-bit and 64-bit programs can’t be linked to 32-bit DLLs, my tools are tied to 32-bit or to use complex, annoying and ugly workarounds.
Because granny32.dll is a Windows library, I can’t make my tools cross-platform without complex, annoying and ugly workarounds.
So I decided to revisit the compression algorithm past weekend and decided to reverse engineer it myself. I got a general high-level overview of the algorithm, but I was overwhelmed by the details, so I kept looking for every bit of info I could find and finally… I found that someone had reverse enginered the algorithm 3 years ago! In fact, it was a work to be included in xoreos-tools, but the author didn’t find the time to properly rewrite it to fit in the project codebase. The work is here: https://github.com/berenm/xoreos-tools/tree/wip/granny-decoder
I have tested it with a bunch of GR2 files, comparing the decompressed output of this implementation with the output of granny32.dll and they are byte by byte identical!
Now the path is clearer for 64-bit and cross-platform .
Do you mean using fbx instead of gr2? I want my engine to directly read NWN2 assets, otherwise hundreds of megas would have to be converted prior to executing my engine, in addition to all the mods.
I’m going to implement PBR. It can be implemented either with a Specular Workflow or a Metalness Workflow. Unreal Engine only supports metalness while Unity supports both. Considering NWN2 assets, I think I’m going with the specular one.
Ok.
There is one limitation you could look into for the interior tileset.If i remember when i was working on a dwarf tileset who was very…huge…well you know dwarf…i encountered trouble as collision and walkmesh are only calculate on height between -y and +y.(i don t remember size as it was some years ago but i think it was between -8 and 8)
Could be nice to uncap this.
Thanks.
.