RenderingWitcher: Difference between revisions

From xoreos Wiki
Jump to navigation Jump to search
(Created page with "In another page of rambling, this is dedicated to rendering notes about The Witcher (Wiedźmin). Witcher has a lot of rewrites from the base Aurora engine, and there's a good deal that functions differently to e.g Neverwinter Nights. There's a more expansive weathering system, it looks like shaders are more common, SpeedTree is used, modelnode formats are a good deal different, and so on. One of the first steps in deciphering much of this is to look at the raw model dat...")
 
No edit summary
 
Line 3: Line 3:
Witcher has a lot of rewrites from the base Aurora engine, and there's a good deal that functions differently to e.g Neverwinter Nights. There's a more expansive weathering system, it looks like shaders are more common, SpeedTree is used, modelnode formats are a good deal different, and so on. One of the first steps in deciphering much of this is to look at the raw model data and try to figure out what it shows, and then how to map it to the rendering system in xoreos.
Witcher has a lot of rewrites from the base Aurora engine, and there's a good deal that functions differently to e.g Neverwinter Nights. There's a more expansive weathering system, it looks like shaders are more common, SpeedTree is used, modelnode formats are a good deal different, and so on. One of the first steps in deciphering much of this is to look at the raw model data and try to figure out what it shows, and then how to map it to the rendering system in xoreos.


First of all, this is an obvious work in progress. There are a lot of unknowns. It's not even certain if blending is always enabled (like with NWN), or if that was fixed: there isn't an api trace of the rendering commands to know this.  
First of all, this is an obvious work in progress. There are a lot of unknowns. It's not even certain if blending is always enabled (like with NWN), or if that was fixed: there isn't an api trace of the rendering commands to know this.
 
== Render Order ==
 
It's worth nothing that Witcher has transparencyHint similar to NWN, but also has a possible "transparency shift" value, and more importantly a "default render list" value for meshes. The name of default render list implies multiple lists of rendering exist, for different reasons. Values of 1, 8, 15, and also -1 (or 0xFFFFFFFF) have been observed for render list. What the common thread is through each hasn't been looked into detail just yet, but it's almost certain that they will have an impact on rendering order.


== Textures ==
== Textures ==

Latest revision as of 22:45, 26 October 2023

In another page of rambling, this is dedicated to rendering notes about The Witcher (Wiedźmin).

Witcher has a lot of rewrites from the base Aurora engine, and there's a good deal that functions differently to e.g Neverwinter Nights. There's a more expansive weathering system, it looks like shaders are more common, SpeedTree is used, modelnode formats are a good deal different, and so on. One of the first steps in deciphering much of this is to look at the raw model data and try to figure out what it shows, and then how to map it to the rendering system in xoreos.

First of all, this is an obvious work in progress. There are a lot of unknowns. It's not even certain if blending is always enabled (like with NWN), or if that was fixed: there isn't an api trace of the rendering commands to know this.

Render Order

It's worth nothing that Witcher has transparencyHint similar to NWN, but also has a possible "transparency shift" value, and more importantly a "default render list" value for meshes. The name of default render list implies multiple lists of rendering exist, for different reasons. Values of 1, 8, 15, and also -1 (or 0xFFFFFFFF) have been observed for render list. What the common thread is through each hasn't been looked into detail just yet, but it's almost certain that they will have an impact on rendering order.

Textures

Modelnodes have multiple defined textures. Generally there are "static" textures defined on a mesh. For the most part these are limited to four, with the first being a lightmap and the second being a diffuse colour. The others, if used, haven't yet been studied. Some meshes don't define a lightmap here, or any other texture - which leads into the second set of texture definitions.

There are an additional set of texture descriptions which can either override or else supplement the static texture definitions. It's likely these might bring shader attributes to the textures, and if a texture name isn't specified outright, then it might just be a shader providing the information. This latter part is possibly what happens when no lightmap is specified in the static list, which is for example observed with the Kaer Morhen cobblestone areas. For those, a shader of "specular" is instead listed, which looks to use the alpha channel of the static diffuse texture for specular highlights (perhaps linked to weather effects).

There is mesh data that has lightmaps without diffuse data. The reasons behind this are not yet known, and proper rendering information isn't forthcoming yet. To make matters worse, some areas such as the mountains overlap with other meshes - but they are partial data and on their own won't overlap everything. This again needs quite a lot of investigation (possibly SpeedTree related).

Node naming, even including a full hierarchy in the name, is not unique. This is not related to LOD system which appears to exist - node (and so mesh) names simply aren't unique! Mesh ids, however, appear to be and can be used to generate unique names for nodes (and meshes).

Lights

Lighting information hasn't been entirely decoded as of yet. Light nodes exist, and have controllers to dictate position (id 84), orientation (id 96), radius (id 340), colour (id 248), a bunch of other parameters. Not all parameters have yet been identified. It's presumed that some related to basic lighting information such as constant, linear, and quadratic coefficients.

The current theory (yet to be explored) is that while NWN calculates the quadratic component based on the light radius, Witcher might instead simply provide it and then use the radius for other purposes (e.g intersection tests).