SEED - Watching entities - Revision history

Grayman: /* Combining entities */

2011-06-22T00:53:36Z

Combining entities

Grayman: /* Culling of entites */

2011-06-22T00:48:08Z

Culling of entites

← Older revision		Revision as of 00:48, 22 June 2011
Line 6:		Line 6:
	# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one drawcall ( [[Drawcalls]] ) instead of multiple. This can improve rendering performance dramatically.		# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one drawcall ( [[Drawcalls]] ) instead of multiple. This can improve rendering performance dramatically.

	== Culling of ~~entites~~ ==		== Culling of entities ==

	Culling of entities works entirely automatic and should always be safe to use. The SEED will know when it should not cull entities, and when it needs to respawn them. If you ever need to disable entity culling, you can do so by setting [[SEED - Spawnargs#cull_range\|'''cull_range''']] to 0.

			Culling of entities is entirely automatic and should always be safe to use. The SEED will know when it should not cull entities, and when it needs to respawn them. If you ever need to disable entity culling, you can do so by setting [[SEED - Spawnargs#cull_range\|'''cull_range''']] to 0.

	== Combining entities ==		== Combining entities ==

Nbohr1more: /* Introduction */

2011-04-10T20:15:29Z

Introduction

← Older revision		Revision as of 20:15, 10 April 2011
Line 4:		Line 4:

	# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present		# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present
	# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls]]~~:Drawcall~~ instead of multiple. This can improve rendering performance dramatically.		# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one drawcall ( [[Drawcalls]] ) instead of multiple. This can improve rendering performance dramatically.

	== Culling of entites ==		== Culling of entites ==

Nbohr1more: /* Introduction */

2011-04-10T20:14:56Z

Introduction

← Older revision		Revision as of 20:14, 10 April 2011
Line 4:		Line 4:

	# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present		# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present
	# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls]] instead of multiple. This can improve rendering performance dramatically.		# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls]]:Drawcall instead of multiple. This can improve rendering performance dramatically.

	== Culling of entites ==		== Culling of entites ==

Nbohr1more: /* Introduction */

2011-04-10T20:14:35Z

Introduction

← Older revision		Revision as of 20:14, 10 April 2011
Line 4:		Line 4:

	# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present		# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present
	# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls~~:Drawcall~~]] instead of multiple. This can improve rendering performance dramatically.		# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls]] instead of multiple. This can improve rendering performance dramatically.

	== Culling of entites ==		== Culling of entites ==

Nbohr1more: /* Introduction */

2011-04-10T20:14:21Z

Introduction

← Older revision		Revision as of 20:14, 10 April 2011
Line 4:		Line 4:

	# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present		# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present
	# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[~~drawall~~]] instead of multiple. This can improve rendering performance dramatically.		# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[Drawcalls:Drawcall]] instead of multiple. This can improve rendering performance dramatically.


	== Culling of entites ==		== Culling of entites ==

Tels: reorg with better intro

2011-02-08T18:17:55Z

reorg with better intro

← Older revision		Revision as of 18:17, 8 February 2011
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

			There are two reasons why you want a [[SEED]] entitiy to "watch" over entities that you created inside the [[DarkRadiant\|editor]], namely the SEED can:

			# '''cull entities''' that are too far away from the player. That means it removes the entity entirely, not merely hiding it as the engine does. This allows you to overcome the [[entity limit]] and also saves memory when not all entities are always present
			# '''combine entities''' that are close together and share the same rendermodel. In this case the combined rendermodel isssues only one [[drawall]] instead of multiple. This can improve rendering performance dramatically.


			== Culling of entites ==

			Culling of entities works entirely automatic and should always be safe to use. The SEED will know when it should not cull entities, and when it needs to respawn them. If you ever need to disable entity culling, you can do so by setting [[SEED - Spawnargs#cull_range\|'''cull_range''']] to 0.


			== Combining entities ==

	Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:		Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:
Line 14:		Line 27:


	=== Why ''can'' ~~combining entities~~ ''improve'' performance? ===		=== Why ''can'' it ''improve'' performance? ===

	* One important feature of the idTech4 engine is that if it has to render multiple things for multiple light passes, then it uses one drawcall per light per "what it renders". This means if you have two tables based on map geometry (brush or patch), then it is better to combine these two func_statics into one, as it will reduce the [[drawcalls]].		* One important feature of the idTech4 engine is that if it has to render multiple things for multiple light passes, then it uses one drawcall per light per "what it renders". This means if you have two tables based on map geometry (brush or patch), then it is better to combine these two func_statics into one, as it will reduce the [[drawcalls]].


	=== Why ''can'' ~~combining entities~~ ''degrade'' performance? ===		=== Why ''can'' it ''degrade'' performance? ===

	*If the two things you combined cross a visportal afterwards, then they will be visible in both areas. That can lead to the situation where the entity is no longer culled, instead it is always fully drawn becaue the engine can't know that only half of it is visible.		*If the two things you combined cross a visportal afterwards, then they will be visible in both areas. That can lead to the situation where the entity is no longer culled, instead it is always fully drawn becaue the engine can't know that only half of it is visible.
Line 26:		Line 39:


	== When should you combine entities? ==		=== When should you combine entities? ===

	* When all parts are hit by the same light(s) (or none)		* When all parts are hit by the same light(s) (or none)
Line 33:		Line 46:


	== How to ==		=== How to ===


	== func_statics based on map geometry ==		==== func_statics based on map geometry ====

	For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.		For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.
Line 41:		Line 55:
	You do not need the SEED to do this.		You do not need the SEED to do this.

	== Entities with a model ==
			==== Entities with a model ====

	For the first two ways there is, however, no way you can combine them in DR. The only recourse you have is by taking a modelling program (like '''Blender''') and then combine the entities in it and create a new model. This is not only time consuming but also cumbersome.		For the first two ways there is, however, no way you can combine them in DR. The only recourse you have is by taking a modelling program (like '''Blender''') and then combine the entities in it and create a new model. This is not only time consuming but also cumbersome.

Tels: update

2011-02-01T08:41:03Z

update

← Older revision		Revision as of 08:41, 1 February 2011
Line 1:		Line 1:
	== ~~Intoduction~~ ==		== Introduction ==

	Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:		Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:
Line 34:		Line 34:

	== How to ==		== How to ==


	== func_statics based on map geometry ==		== func_statics based on map geometry ==
Line 40:		Line 39:
	For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.		For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.

			You do not need the SEED to do this.

	== Entities with a model ==		== Entities with a model ==
Line 47:		Line 47:
	And here is where the SEED entity comes into play.		And here is where the SEED entity comes into play.

	For our example, we create 6 banners on a wall. 5 use the same model (ragged banner, 3 with one skin, 2 with another skin) and 1 uses a different model (big banner). Here is how it looks in the editor:		If you have either set [[#combine\|'''combine''']] to '''1''' on the SEED, or set [[#seed_combine\|'''seed_combine''']] to '''1''' on the target, then the SEED will combine all multiple models of the same name into one multi-model entity.To provent it, set '''seed_combine''' to 0 on the target entity.

			For our example, we create 6 banners on a wall. 5 use the same model (ragged banner, 3 with one skin, 2 with another skin) and 1 uses a different model (big banner). Then we target one of the banners from the SEED and set:

			"seed_watch_brethren" "1"

			on it. Here is how it looks in the editor:

	[[Image:SEED Watch.jpg\|600px\|Inside DR]]		[[Image:SEED Watch.jpg\|600px\|Inside DR]]
Line 56:		Line 62:

	You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).		You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).

			The other "seed_" spawnargs (like '''seed_floor''', '''seed_spacing''' etc.) are ignored on the target entity. The only relevant spawnargs are '''lod_''' and '''hide_distance''' - these cause the LOD system to kick in. Also, do not forget to put a '''hide_distance''' on the target entity, or the SEED would never cull the entities it watches.

	{{seed}}		{{seed}}

Tels: use template

2011-02-01T08:36:00Z

use template

← Older revision		Revision as of 08:36, 1 February 2011
Line 57:		Line 57:
	You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).		You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).

	~~== See also ==~~		{{seed}}

	* [[SEED]]
	* [[SEED Usage]] - Examples on how to use SEED in real-map scenarios
	* [[SEED - Known bugs]]

	{{~~editing~~}}

Tels: add links and formatting

2011-01-31T22:25:25Z

add links and formatting

← Older revision		Revision as of 22:25, 31 January 2011
Line 3:		Line 3:
	Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:		Suppose you build a highly-detailed scene in DR and you want to improve the performance of the scene. There are three different kind of ways (apart from worldspawn and any moveables/lights etc) you can use to add visible things to such a scene:

	# static entities with an entity def (f.i. ~~[b]~~atdm:statue_aphrodite~~[/b]~~). This is basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE). You'd use "Create entity" in DR to create such a thing.		# static entities with an entity def (f.i. '''atdm:statue_aphrodite'''). This is basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE). You'd use "Create entity" in DR to create such a thing.
	# static models (f.i. ~~[b]~~models/darkmod/decorative/wall/longbanner_ragged.lwo~~[/b]~~). This is also basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE), except that the spawnclass is "func_static" for all of them. You'd use "Create model" in DR to create such a thing.		# static models (f.i. '''models/darkmod/decorative/wall/longbanner_ragged.lwo'''). This is also basically a func_static with a model spawnarg pointing to a model in a file (.LWO, or .ASE), except that the spawnclass is "func_static" for all of them. You'd use "Create model" in DR to create such a thing.
	# func_statics based on brushes or patches. You'd use "Create func_static" in DR to create such a thing.		# func_statics based on brushes or patches. You'd use "Create func_static" in DR to create such a thing.

Line 26:		Line 26:


	== When should you combine entities: ==		== When should you combine entities? ==

	* When all parts are hit by the same light(s) (or none)		* When all parts are hit by the same light(s) (or none)
Line 33:		Line 33:


	== How to ~~combine entities~~ ==		== How to ==


	== func_statics ~~base~~ on map geometry ==		== func_statics based on map geometry ==

	For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.		For the third way this indeed works: Select first func_static, "Revert to worldspawn", do the same for the second, then select both, and use "Convert to func_static". Et voila, one merged entity which will improve performance.


	== Entities with a model ==		== Entities with a model ==
Line 55:		Line 56:

	You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).		You can see that afterwards there are only two entities instead of 5 (ignore the missing banner far-away, I did make the screenshot before adding it to the map).

			== See also ==

			* [[SEED]]
			* [[SEED Usage]] - Examples on how to use SEED in real-map scenarios
			* [[SEED - Known bugs]]

	{{editing}}		{{editing}}

← Older revision		Revision as of 00:53, 22 June 2011
Line 20:		Line 20:
	There are fundamental differences betwen the first two cases and the third case:		There are fundamental differences betwen the first two cases and the third case:

	In both the first cases you have an entity, and a model in a file. This means, it is always possible (inside the engine) to load the model data by just ~~given~~ the file. Also, the engine will only ever keep one copy of the model data around (sharing it).		In both the first cases you have an entity, and a model in a file. This means, it is always possible (inside the engine) to load the model data by just giving the file. Also, the engine will only ever keep one copy of the model data around (sharing it).

	In the third way, you have the "model data" stored in the map file. Not only is it not possible to reload that data (as there is no model file name), but also all the data is duplicated if you duplicate such a func_static in DR.		In the third way, you have the "model data" stored in the map file. Not only is it not possible to reload that data (as there is no model file name), but also all the data is duplicated if you duplicate such a func_static in DR.
Line 34:		Line 34:
	*If the two things you combined cross a visportal afterwards, then they will be visible in both areas. That can lead to the situation where the entity is no longer culled, instead it is always fully drawn becaue the engine can't know that only half of it is visible.		*If the two things you combined cross a visportal afterwards, then they will be visible in both areas. That can lead to the situation where the entity is no longer culled, instead it is always fully drawn becaue the engine can't know that only half of it is visible.
	*If each part of the entity is hit by one light, then the combined entity is hit by two lights, and thus both parts are drawn twice, where formerly only one part was draw once for one light, and the other for the other light.		*If each part of the entity is hit by one light, then the combined entity is hit by two lights, and thus both parts are drawn twice, where formerly only one part was draw once for one light, and the other for the other light.
	*If the combined entity covers an huge area, the engine will often ~~thing~~ things are inside that entity space, even ~~tho~~ they are "between" the parts. This can lead to poor performance in case of stims or collision detection. For static entities (even solid ones) this is usually no concern.		*If the combined entity covers an huge area, the engine will often think things are inside that entity space, even though they are "between" the parts. This can lead to poor performance in case of stims or collision detection. For static entities (even solid ones) this is usually no concern.


Line 41:		Line 41:
	* When all parts are hit by the same light(s) (or none)		* When all parts are hit by the same light(s) (or none)
	* AND all parts are in the same visportaled area		* AND all parts are in the same visportaled area
	* AND all parts are ~~reasonable~~ close together (a few 1000 doom units)		* AND all parts are reasonably close together (a few 1000 doom units)


Line 60:		Line 60:
	And here is where the SEED entity comes into play.		And here is where the SEED entity comes into play.

	If you have either set [[#combine\|'''combine''']] to '''1''' on the SEED, or set [[#seed_combine\|'''seed_combine''']] to '''1''' on the target, then the SEED will combine all multiple models of the same name into one multi-model entity.To ~~provent~~ it, set '''seed_combine''' to 0 on the target entity.		If you have either set [[#combine\|'''combine''']] to '''1''' on the SEED, or set [[#seed_combine\|'''seed_combine''']] to '''1''' on the target, then the SEED will combine all multiple models of the same name into one multi-model entity. To prevent it, set '''seed_combine''' to 0 on the target entity.

	For our example, we create 6 banners on a wall. 5 use the same model (ragged banner, 3 with one skin, 2 with another skin) and 1 uses a different model (big banner). Then we target one of the banners from the SEED and set:		For our example, we create 6 banners on a wall. 5 use the same model (ragged banner, 3 with one skin, 2 with another skin) and 1 uses a different model (big banner). Then we target one of the banners from the SEED and set: