RenderRambling - Revision history

Mirv at 09:54, 26 September 2023

2023-09-26T09:54:48Z

← Older revision		Revision as of 09:54, 26 September 2023
Line 70:		Line 70:
	The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.		The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.
	This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.		This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.

	~~== Render Order ==~~
	Looks like KotOR at least, and possibly NWN, bake rendering order of modelnodes into the mdl file format itself. In KotOR this has helped render blast scorch marks correctly over everything else. Unfortunately the models overlap each other, so model rendering order (in addition to modelnode rendering order) is possibly also baked into the loading order somehow. This is considered somewhat gross, and how the tools managed to do that, or if it was up to the artists, seems to be a less than optimal way of handling things.

	== Fade In/Out ==		== Fade In/Out ==
	Particularly with NWN, possibly other games, there's object fade in and out as the camera moves around. This is intended to stop geometry from obscuring the player's view of a scene. This is not actually determined by transparency hints; many meshes with fade in/out can have transparency hints of zero. Instead, the tilefade attribute marks meshes this applies to. So far there have been seen values of 0, 1, 2, and 4. These are theorised to indicate the distance that fade in/out is applied, with 0 being fade disabled for that mesh.		Particularly with NWN, possibly other games, there's object fade in and out as the camera moves around. This is intended to stop geometry from obscuring the player's view of a scene. This is not actually determined by transparency hints; many meshes with fade in/out can have transparency hints of zero. Instead, the tilefade attribute marks meshes this applies to. So far there have been seen values of 0, 1, 2, and 4. These are theorised to indicate the distance that fade in/out is applied, with 0 being fade disabled for that mesh.
	Fade in/out would work by adjusting the alpha value of the mesh. This impacts the rendering queue - once the alpha value is less than e.g 90% it should move to the transparency queues. Below 20% and just don't render that object.		Fade in/out would work by adjusting the alpha value of the mesh. This impacts the rendering queue - once the alpha value is less than e.g 90% it should move to the transparency queues. Below 20% and just don't render that object.

			= Render Order =
			Looks like KotOR at least, and possibly NWN, bake rendering order of modelnodes into the mdl file format itself. In KotOR this has helped render blast scorch marks correctly over everything else. Unfortunately the models overlap each other, so model rendering order (in addition to modelnode rendering order) is possibly also baked into the loading order somehow. This is considered somewhat gross, and how the tools managed to do that, or if it was up to the artists, seems to be a less than optimal way of handling things.

			Regardless of reasons, the pre-baked rendering order of static geometry is critical in getting everything to show up properly. Everything has blending enabled by default, even objects that are actually opaque, which is just the way the Aurora engine seems to work. This is fairly inefficient for a GPU, but for whatever reason was a design decision that someone took which has wide ranging and often subtle impacts elsewhere. With everything being able to offer transparency, and with the mdl format not giving enough secondary hints as to what is really transparent and what is not, then everything is pretty much stuck on using the pre-baked rendering order. This has side effects, for example geometry rendering order cannot be sorted by shader for batched rendering.

			Static geometry will require this rendering order, but dynamic geometry, e.g player characters, cannot be pre-baked into the overall area rendering order. Within a single model it can, but not within an entire scene. So rendering will very likely end up as: render static geometry, render dynamic geometry, render special effects in there somewhere. This means the rendering pipeline will need to know the difference between static and dynamic geometry, which is not something currently implemented. This information can be specific to games; at the time of writing it's not certain if each game should offer a customised top level "renderWorld" callback, or if each game should provide a list of static and dynamic objects into the top level graphics handling layer.

Mirv at 22:41, 21 September 2023

2023-09-21T22:41:40Z

← Older revision		Revision as of 22:41, 21 September 2023
Line 70:		Line 70:
	The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.		The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.
	This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.		This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.

			== Render Order ==
			Looks like KotOR at least, and possibly NWN, bake rendering order of modelnodes into the mdl file format itself. In KotOR this has helped render blast scorch marks correctly over everything else. Unfortunately the models overlap each other, so model rendering order (in addition to modelnode rendering order) is possibly also baked into the loading order somehow. This is considered somewhat gross, and how the tools managed to do that, or if it was up to the artists, seems to be a less than optimal way of handling things.

	== Fade In/Out ==		== Fade In/Out ==
	Particularly with NWN, possibly other games, there's object fade in and out as the camera moves around. This is intended to stop geometry from obscuring the player's view of a scene. This is not actually determined by transparency hints; many meshes with fade in/out can have transparency hints of zero. Instead, the tilefade attribute marks meshes this applies to. So far there have been seen values of 0, 1, 2, and 4. These are theorised to indicate the distance that fade in/out is applied, with 0 being fade disabled for that mesh.		Particularly with NWN, possibly other games, there's object fade in and out as the camera moves around. This is intended to stop geometry from obscuring the player's view of a scene. This is not actually determined by transparency hints; many meshes with fade in/out can have transparency hints of zero. Instead, the tilefade attribute marks meshes this applies to. So far there have been seen values of 0, 1, 2, and 4. These are theorised to indicate the distance that fade in/out is applied, with 0 being fade disabled for that mesh.
	Fade in/out would work by adjusting the alpha value of the mesh. This impacts the rendering queue - once the alpha value is less than e.g 90% it should move to the transparency queues. Below 20% and just don't render that object.		Fade in/out would work by adjusting the alpha value of the mesh. This impacts the rendering queue - once the alpha value is less than e.g 90% it should move to the transparency queues. Below 20% and just don't render that object.

Mirv at 22:26, 16 September 2023

2023-09-16T22:26:37Z

← Older revision		Revision as of 22:26, 16 September 2023
Line 67:		Line 67:
	Note: looking at Knights of the Old Republic, it has been observed that "transparency hints" of different values to NWN exist. While NWN primarily has a uint32_t value of 0 or 1 (at least so far), KotOR has 0, 1, 3, 5, and 8 at least. Current theory is to treat this as a priority system: lower numbers have higher rendering priority.		Note: looking at Knights of the Old Republic, it has been observed that "transparency hints" of different values to NWN exist. While NWN primarily has a uint32_t value of 0 or 1 (at least so far), KotOR has 0, 1, 3, 5, and 8 at least. Current theory is to treat this as a priority system: lower numbers have higher rendering priority.

			== Queues ==
	The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.		The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.
	This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.		This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.

			== Fade In/Out ==
			Particularly with NWN, possibly other games, there's object fade in and out as the camera moves around. This is intended to stop geometry from obscuring the player's view of a scene. This is not actually determined by transparency hints; many meshes with fade in/out can have transparency hints of zero. Instead, the tilefade attribute marks meshes this applies to. So far there have been seen values of 0, 1, 2, and 4. These are theorised to indicate the distance that fade in/out is applied, with 0 being fade disabled for that mesh.
			Fade in/out would work by adjusting the alpha value of the mesh. This impacts the rendering queue - once the alpha value is less than e.g 90% it should move to the transparency queues. Below 20% and just don't render that object.

Mirv at 16:23, 16 September 2023

2023-09-16T16:23:16Z

← Older revision		Revision as of 16:23, 16 September 2023
Line 65:		Line 65:
	* After child nodes are drawn, now draw dynamic and transparent geometry.		* After child nodes are drawn, now draw dynamic and transparent geometry.
	Very recursive-friendly, but also requires knowledge of game data. NWN for example might have rendered tiles last to be sure that the fade in and out geometry doesn't obscure characters, placeables, etc. Each game might do something slightly different in this regard, so it would mean each game would then need a customised bit of world rendering code. Possibly a good idea anyway, but attempts at a more generic approach will be used to start with.		Very recursive-friendly, but also requires knowledge of game data. NWN for example might have rendered tiles last to be sure that the fade in and out geometry doesn't obscure characters, placeables, etc. Each game might do something slightly different in this regard, so it would mean each game would then need a customised bit of world rendering code. Possibly a good idea anyway, but attempts at a more generic approach will be used to start with.
			Note: looking at Knights of the Old Republic, it has been observed that "transparency hints" of different values to NWN exist. While NWN primarily has a uint32_t value of 0 or 1 (at least so far), KotOR has 0, 1, 3, 5, and 8 at least. Current theory is to treat this as a priority system: lower numbers have higher rendering priority.

	The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.		The rendering queue system so far appears to handle rendering order fairly well for most games. The original intent behind the queues was to perform batched rendering where possible and so improve overall rendering performance. That's not being now (far too difficult to maintain just yet, but can be revisited much further down the line), but the idea of multiple queues for opaque and transparent (translucent more accurately) objects stood up quite well. Instead of drawing geometry as model nodes are traversed, place them into appropriate queues which can be sorted if necessary before rendering.
	This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.		This approach separates transparency from hierarchies, allowing overlapping model volumes to be more correctly drawn. It has helped a lot with KotOR, which has a lot of windows, so there's no reason not to continue using this setup. The only real change is that previously a lot of extra data was included to directly access material data, surface data, alpha values, position, etc. The render queues could instead just keep a pointer to the node and render it directly as needed. There are some challenges with that approach, mostly that immediate node rendering must rely on updated _renderTransform values (basically world coordinate transforms), and some of the rendering function call interfaces might need a bit of tweaking, but on the whole there are not insurmountable issues; tweaks rather than overhauls.

Mirv at 15:40, 9 September 2023

2023-09-09T15:40:17Z

← Older revision		Revision as of 15:40, 9 September 2023
Line 50:		Line 50:

	Static lights can be placed into a quadtree (or some kind of tree setup) to quickly perform volume intersection comparisons. This should be a moderate performance increase given that every single rendered node will use it every single frame, but it's something that will need investigation. Dynamic lights are likely best kept in just a simple list, but fortunately they're expected to be far fewer than static lights.		Static lights can be placed into a quadtree (or some kind of tree setup) to quickly perform volume intersection comparisons. This should be a moderate performance increase given that every single rendered node will use it every single frame, but it's something that will need investigation. Dynamic lights are likely best kept in just a simple list, but fortunately they're expected to be far fewer than static lights.
	It's highly recommended to stick with fade in and fade out to trim the list of active lights at first, as this is far simpler to code and maintain, and it unifies how lights are handled. It just depends on performance if ~~that~~ something further should be done.		It's highly recommended to stick with fade in and fade out to trim the list of active lights at first, as this is far simpler to code and maintain, and it unifies how lights are handled. It just depends on performance if something further should be done.

	Light radius and multiplier values appear to be directly related to OpenGL lighting model values. The linear coefficient looks to be the multiplier value directly (normally 1.0f), while the radius doesn't directly map to the quadratic coefficient. Under the assumption that the half-radius point equates to roughly 0.5f attenuation, then the quadratic component is being calculated as: 1.0f / ((radius0.5f)(radius*0.5f)). Now that lighting is in place then any adjustments here should be relatively trivial.		Light radius and multiplier values appear to be directly related to OpenGL lighting model values. The linear coefficient looks to be the multiplier value directly (normally 1.0f), while the radius doesn't directly map to the quadratic coefficient. Under the assumption that the half-radius point equates to roughly 0.5f attenuation, then the quadratic component is being calculated as: 1.0f / ((radius0.5f)(radius*0.5f)). Now that lighting is in place then any adjustments here should be relatively trivial.

Mirv at 11:58, 9 September 2023

2023-09-09T11:58:14Z

← Older revision		Revision as of 11:58, 9 September 2023
Line 51:		Line 51:
	Static lights can be placed into a quadtree (or some kind of tree setup) to quickly perform volume intersection comparisons. This should be a moderate performance increase given that every single rendered node will use it every single frame, but it's something that will need investigation. Dynamic lights are likely best kept in just a simple list, but fortunately they're expected to be far fewer than static lights.		Static lights can be placed into a quadtree (or some kind of tree setup) to quickly perform volume intersection comparisons. This should be a moderate performance increase given that every single rendered node will use it every single frame, but it's something that will need investigation. Dynamic lights are likely best kept in just a simple list, but fortunately they're expected to be far fewer than static lights.
	It's highly recommended to stick with fade in and fade out to trim the list of active lights at first, as this is far simpler to code and maintain, and it unifies how lights are handled. It just depends on performance if that something further should be done.		It's highly recommended to stick with fade in and fade out to trim the list of active lights at first, as this is far simpler to code and maintain, and it unifies how lights are handled. It just depends on performance if that something further should be done.

			Light radius and multiplier values appear to be directly related to OpenGL lighting model values. The linear coefficient looks to be the multiplier value directly (normally 1.0f), while the radius doesn't directly map to the quadratic coefficient. Under the assumption that the half-radius point equates to roughly 0.5f attenuation, then the quadratic component is being calculated as: 1.0f / ((radius0.5f)(radius*0.5f)). Now that lighting is in place then any adjustments here should be relatively trivial.

	= Transparency =		= Transparency =

Mirv at 11:45, 9 September 2023

2023-09-09T11:45:34Z

@@ Line 1: / Line 1: @@
 Welcome to a page to keep track of notes about the rendering in xoreos. For now it is focusing on Neverwinter Nights (or NWN for short). Occasionally other games are actually tested as well, but NWN serves as the primary testing ground with the hopes that it will at least be semi-relevant for other games.
-This rambling start is coming about from recent attempts to incorporate lighting into NWN, which has exposed some weaknesses in the render pipeline structuring. For a bit of history, the rendering has change much and was done with knowledge of how things "should be" at the time - this knowledge has changed, and with it the realisation that some of the nice ways of handling rendering will need workarounds and become not so nice. By rambling a little here of how things are, it's hoped that a way forward will become more clear.
+This rambling start is coming about from recent attempts to incorporate lighting into NWN, which has exposed some weaknesses in the render pipeline structuring. For a bit of history, the rendering has changed much and was done with knowledge of how things "should be" at the time - this knowledge has changed, and with it the realisation that some of the nice ways of handling rendering will need workarounds and become not so nice. By rambling a little here of how things are, it's hoped that a way forward will become more clear.
 Confused yet? Yes? Good. Me too.
@@ Line 23: / Line 24: @@
 On the topic of tiles and main lights, it looks like main lights should have a radius of 7. This is close to the diagonal "radius" of a tile (each tile is 5x5). The light radius and other properties other than colour aren't currently known where to find. They might be hard coded. Main light radius should cover the tile it's part of, but not extend too far beyond: enough to blend into other tiles, but not enough to cover entire large rooms or bleed through walls.
----
+== Playing Around ==
 Continuing on from above (perhaps this should be put into a different page) and there are a few advancements in local builds. Light information, it turns out, is stored in modelnode controllers. This makes sense really: controllers can act as animation keyframes, and the radius, intensity, colour, etc, of a light could all change. Think of a flickering candle, or the light given off by fireworks: they aren't static lights. Inspecting controllers from model files and it appears that tile main lights will generally have at least a radius and multiplier value. The radius of main light 1 looks to generally be 14, with main light 2 being 5. The multiplier value generally looks to be 1. For candles, the multiplier has been zero. I'm not quite sure how the radius and multiplier values map to OpenGL lighting equations: the radius very likely impacts the linear coefficient, probably based on the light attenuation falling to some value (0.5, 0.25, 0.1, could be anything really) but the multiplier? No idea currently.
@@ Line 36: / Line 37: @@
 Lights are effectively going to be generated for each object and their duration tied to the object, but referencing model data, possibly individually animated, and globally available to see which objects each light influences. Also, tile lights are treated slightly differently just because.

Mirv at 23:17, 3 September 2023

2023-09-03T23:17:38Z

← Older revision		Revision as of 23:17, 3 September 2023
Line 29:		Line 29:
	All this is very nice and allows some playing around with lighting to see what fits. Mesh ambient values are just source colour component-wise multipliers, easily added to the shaders. On the topic of mesh, let's take a step back a moment and look at modelnodes in general. Currently all mesh data is added to a mesh manager to prevent duplication. This is now wrong. Model caches mean that model files are only loaded once, and so the mesh data is only going to exist once within the model's node hierarchy. There's simply no need to use the dedicated mesh manager in this area anymore, and removing the usage means cleaner code and fewer hacks (always nice).		All this is very nice and allows some playing around with lighting to see what fits. Mesh ambient values are just source colour component-wise multipliers, easily added to the shaders. On the topic of mesh, let's take a step back a moment and look at modelnodes in general. Currently all mesh data is added to a mesh manager to prevent duplication. This is now wrong. Model caches mean that model files are only loaded once, and so the mesh data is only going to exist once within the model's node hierarchy. There's simply no need to use the dedicated mesh manager in this area anymore, and removing the usage means cleaner code and fewer hacks (always nice).
	(--edit: actually, seems that model files are _not_ cached currently, they're loaded multiple times - this should probably change!)		(--edit: actually, seems that model files are _not_ cached currently, they're loaded multiple times - this should probably change!)
			(--edit2: fixing some of the unique mesh naming gives all the mesh data sharing benefits, but allows the same model to be loaded multiple times - which effectively gives model instancing anyway. To avoid reloading from disk accesses, just load the model file into memory and parse directly from that if necessary. Mesh manager lives on.)

	Not to say that the mesh manager is entirely useless. It's still good to keep some engine default meshes around: wireframe boxes for debug and development purposes (showing bounding volumes for example), squares, circles, that sort of thing. So it still serves a important purpose, just not for the mesh data from nodes.		Not to say that the mesh manager is entirely useless. It's still good to keep some engine default meshes around: wireframe boxes for debug and development purposes (showing bounding volumes for example), squares, circles, that sort of thing. So it still serves a important purpose, just not for the mesh data from nodes.

Mirv at 23:54, 1 September 2023

2023-09-01T23:54:52Z

← Older revision		Revision as of 23:54, 1 September 2023
Line 28:		Line 28:

	All this is very nice and allows some playing around with lighting to see what fits. Mesh ambient values are just source colour component-wise multipliers, easily added to the shaders. On the topic of mesh, let's take a step back a moment and look at modelnodes in general. Currently all mesh data is added to a mesh manager to prevent duplication. This is now wrong. Model caches mean that model files are only loaded once, and so the mesh data is only going to exist once within the model's node hierarchy. There's simply no need to use the dedicated mesh manager in this area anymore, and removing the usage means cleaner code and fewer hacks (always nice).		All this is very nice and allows some playing around with lighting to see what fits. Mesh ambient values are just source colour component-wise multipliers, easily added to the shaders. On the topic of mesh, let's take a step back a moment and look at modelnodes in general. Currently all mesh data is added to a mesh manager to prevent duplication. This is now wrong. Model caches mean that model files are only loaded once, and so the mesh data is only going to exist once within the model's node hierarchy. There's simply no need to use the dedicated mesh manager in this area anymore, and removing the usage means cleaner code and fewer hacks (always nice).
			(--edit: actually, seems that model files are _not_ cached currently, they're loaded multiple times - this should probably change!)

	Not to say that the mesh manager is entirely useless. It's still good to keep some engine default meshes around: wireframe boxes for debug and development purposes (showing bounding volumes for example), squares, circles, that sort of thing. So it still serves a important purpose, just not for the mesh data from nodes.		Not to say that the mesh manager is entirely useless. It's still good to keep some engine default meshes around: wireframe boxes for debug and development purposes (showing bounding volumes for example), squares, circles, that sort of thing. So it still serves a important purpose, just not for the mesh data from nodes.

Mirv at 23:00, 1 September 2023

2023-09-01T23:00:51Z

← Older revision		Revision as of 23:00, 1 September 2023
Line 22:		Line 22:

	On the topic of tiles and main lights, it looks like main lights should have a radius of 7. This is close to the diagonal "radius" of a tile (each tile is 5x5). The light radius and other properties other than colour aren't currently known where to find. They might be hard coded. Main light radius should cover the tile it's part of, but not extend too far beyond: enough to blend into other tiles, but not enough to cover entire large rooms or bleed through walls.		On the topic of tiles and main lights, it looks like main lights should have a radius of 7. This is close to the diagonal "radius" of a tile (each tile is 5x5). The light radius and other properties other than colour aren't currently known where to find. They might be hard coded. Main light radius should cover the tile it's part of, but not extend too far beyond: enough to blend into other tiles, but not enough to cover entire large rooms or bleed through walls.

			---

			Continuing on from above (perhaps this should be put into a different page) and there are a few advancements in local builds. Light information, it turns out, is stored in modelnode controllers. This makes sense really: controllers can act as animation keyframes, and the radius, intensity, colour, etc, of a light could all change. Think of a flickering candle, or the light given off by fireworks: they aren't static lights. Inspecting controllers from model files and it appears that tile main lights will generally have at least a radius and multiplier value. The radius of main light 1 looks to generally be 14, with main light 2 being 5. The multiplier value generally looks to be 1. For candles, the multiplier has been zero. I'm not quite sure how the radius and multiplier values map to OpenGL lighting equations: the radius very likely impacts the linear coefficient, probably based on the light attenuation falling to some value (0.5, 0.25, 0.1, could be anything really) but the multiplier? No idea currently.

			All this is very nice and allows some playing around with lighting to see what fits. Mesh ambient values are just source colour component-wise multipliers, easily added to the shaders. On the topic of mesh, let's take a step back a moment and look at modelnodes in general. Currently all mesh data is added to a mesh manager to prevent duplication. This is now wrong. Model caches mean that model files are only loaded once, and so the mesh data is only going to exist once within the model's node hierarchy. There's simply no need to use the dedicated mesh manager in this area anymore, and removing the usage means cleaner code and fewer hacks (always nice).

			Not to say that the mesh manager is entirely useless. It's still good to keep some engine default meshes around: wireframe boxes for debug and development purposes (showing bounding volumes for example), squares, circles, that sort of thing. So it still serves a important purpose, just not for the mesh data from nodes.

			Models are generally referenced by a placeable, door, character, or some such class. Models can be immediately rendered, kept in a cache and removed when nothing more uses it, provide animation details, attachment points, etc - but a model is still only referenced. This means the model data and its entire hierarchy shouldn't be modified, or else multiple objects might be impacted. It all gets a bit more murky from here. Objects will need to track which state their reference to the model is (door open, closed, damaged, etc), which keyframe might be applied to animations, if something is attached (a character holding a weapon) location, orientation, scaling that's applied, and so on. All of that isn't so difficult, but models can also contain lights (normal lights and shadow casting lights) and emitters (particle effects). Lights and emitters aren't simply rendered as the node hierarchy is traversed, and the list of lights impacting each object must be runtime calculated.

			Lights are effectively going to be generated for each object and their duration tied to the object, but referencing model data, possibly individually animated, and globally available to see which objects each light influences. Also, tile lights are treated slightly differently just because.